On Mon, 2005-10-31 at 14:48 -0800, Chris Travers wrote:
> Simon Riggs wrote:
> >Your point was about cache efficiency as an argument for not increasing
> >shared_buffers. Politely, I don't accept that argument. Clearly, there
> >are some other considerations (for which I agree completely) but thos
On Mon, 2005-10-31 at 16:12, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > I was mainly wondering if that behaviour had changed, if, when the data
> > are released, they are still held in shared memory until forced out by
> > newer / more popular data. Which would make the buffer
On Mon, 2005-10-31 at 15:44, Simon Riggs wrote:
> On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:
>
> > As I understand it, when the last backend referencing a collection of
> > data stops referencing it, that the buffers holding that data are
> > released, and if, a second later, another
Scott Marlowe <[EMAIL PROTECTED]> writes:
> I was mainly wondering if that behaviour had changed, if, when the data
> are released, they are still held in shared memory until forced out by
> newer / more popular data. Which would make the buffer pool a real
> cache.
Huh? It's always done that.
On Mon, Oct 31, 2005 at 02:50:31PM -0600, Scott Marlowe wrote:
> > Your point was about cache efficiency as an argument for not increasing
> > shared_buffers. Politely, I don't accept that argument. Clearly, there
> > are some other considerations (for which I agree completely) but those
> > don't
On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:
> As I understand it, when the last backend referencing a collection of
> data stops referencing it, that the buffers holding that data are
> released, and if, a second later, another backend wants the data, then
> it has to go to the Kernel
On Mon, 2005-10-31 at 10:58, Simon Riggs wrote:
> On Mon, 2005-10-31 at 15:44 +0100, Martijn van Oosterhout wrote:
> > On Mon, Oct 31, 2005 at 01:34:12PM +, Simon Riggs wrote:
> > > > Secondly, you're assuming that PostgreSQLs caching is at least as
> > > > efficient as the OS caching, which is
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-10-31 at 09:35 -0500, Tom Lane wrote:
>> The real point is that RAM dedicated to shared buffers can't be used for
>> anything else [1], whereas letting the kernel manage it gives you some
>> flexibility (for instance, to deal with transient lar
On Mon, 2005-10-31 at 09:35 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
> >> On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
> >>> I'm not sure we have any good tests of that either way, do we? I'
On Mon, 2005-10-31 at 15:44 +0100, Martijn van Oosterhout wrote:
> On Mon, Oct 31, 2005 at 01:34:12PM +, Simon Riggs wrote:
> > > Secondly, you're assuming that PostgreSQLs caching is at least as
> > > efficient as the OS caching, which is more of an assertion than
> > > anything else.
> >
> >
On Mon, Oct 31, 2005 at 09:54:39AM -0500, Tom Lane wrote:
> Note however that it's reasonable to think that 8.1 may do better than
> 8.0 did at performing well with large values of shared_buffers,
> primarily because we got rid of the StrategyDirtyBufferList overhead:
> http://archives.postgresql.o
Martijn van Oosterhout writes:
> There have been tests that demonstrate that you can raise the buffers
> to a certain point which is optimal and after that it just doesn't
> help [1]. They peg optimal size at 5-10% of memory.
> [1] http://archives.postgresql.org/pgsql-performance/2004-10/msg00110.
On Mon, Oct 31, 2005 at 01:34:12PM +, Simon Riggs wrote:
> > Secondly, you're assuming that PostgreSQLs caching is at least as
> > efficient as the OS caching, which is more of an assertion than
> > anything else.
>
> Do you doubt that? Why would shared_buffers be variable otherwise?
Because
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
>> On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
>>> I'm not sure we have any good tests of that either way, do we? I'm not
>>> certain why we would trust OS cache any more than
> Anyway, the original writer didn't specify an architechure. If it is a
> 32bit one it is entirly possible that the memory map simply has no
> large contiguous space to map the shared memory.
it's 32bit. The actual problem of giving more buffers to postgresql
was solved with the help of the follo
On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
> On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
> > > 8.0 can't go past 2Gb of shared memory, and there is really no reason
> > > to try because its performance will get worse not better with more than
> > > about 5
On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
> > 8.0 can't go past 2Gb of shared memory, and there is really no reason
> > to try because its performance will get worse not better with more than
> > about 5 shared buffers.
>
> Unless you turn off the bgwriter, in which case goi
On Sun, 2005-10-30 at 23:08 -0500, Tom Lane wrote:
> Vlad <[EMAIL PROTECTED]> writes:
> > I'm looking for some help in regards to letting Posresql use more
> > memory.
>
> 8.0 can't go past 2Gb of shared memory, and there is really no reason
> to try because its performance will get worse not bett
Tom,
I understood your point on memory usage. Out of curiosity - 115200
buffers seems to be little less than 1 gig (I assume 1 buffer = 8k),
so I could not get any closer to 2gigs anyways
Is it practical experience that more than 5 buggers actually hurts
postgresql performance? Any ideas
Vlad <[EMAIL PROTECTED]> writes:
> I'm looking for some help in regards to letting Posresql use more
> memory.
8.0 can't go past 2Gb of shared memory, and there is really no reason
to try because its performance will get worse not better with more than
about 5 shared buffers.
8.1 will relax t
Hi,
I'm looking for some help in regards to letting Posresql use more
memory. It fails to start with this message:
shmat(id=65536) failed: Cannot allocate shared bufers
Max buffers I can start it with is 115200. Server has 4gig of RAM,
I've adjuted MAXDSIZ to 2.5Gigs. Here is other kernel settin
21 matches
Mail list logo
