On Mon, 2009-09-28 at 10:36 -0700, Josh Berkus wrote:
> On 9/26/09 8:19 AM, Greg Smith wrote:
> > This means that the question you want an answer to is "if the OS cache
> > isn't really available, where does giving memory to shared_buffers
> > becomes less efficient than not caching things at all?"
On 9/26/09 8:19 AM, Greg Smith wrote:
> This means that the question you want an answer to is "if the OS cache
> isn't really available, where does giving memory to shared_buffers
> becomes less efficient than not caching things at all?" My guess is
> that this number is much larger than 10GB, but
On Sat, 26 Sep 2009, Jeff Janes wrote:
On Sat, Sep 26, 2009 at 8:19 AM, Greg Smith wrote:
Another problem spot are checkpoints. If you dirty a very large buffer
cache, that whole thing will have to get dumped to disk eventually, and on
some workloads people have found they have to reduce sha
On Sat, Sep 26, 2009 at 8:19 AM, Greg Smith wrote:
>
> Another problem spot are checkpoints. If you dirty a very large buffer
> cache, that whole thing will have to get dumped to disk eventually, and on
> some workloads people have found they have to reduce shared_buffers
> specifically to keep t
On Sat, Sep 26, 2009 at 9:57 AM, Gerhard Wiesinger wrote:
> On Sat, 26 Sep 2009, Greg Smith wrote:
>
>> On Fri, 25 Sep 2009, Jeff Janes wrote:
>>
>>> Does it do this even if the block was already in shared_buffers?
>>
>> Usually not. The buffer ring algorithm is used to manage pages that are
>> r
On Fri, 25 Sep 2009, Jeff Janes wrote:
Does it do this even if the block was already in shared_buffers?
Usually not. The buffer ring algorithm is used to manage pages that are
read in specifically to satisfy a sequential scan (there's a slightly
different ring method used for VACUUM too).
Is there any practical limit to the number of shared buffers PG 8.3.7
can handle before more becomes counter-productive?
It is more efficient to have the page in shared buffers, rather than doing
a context switch to the OS, copying the entire page from the OS's cache
into shared buffers,
On Sat, 26 Sep 2009, Greg Smith wrote:
On Fri, 25 Sep 2009, Jeff Janes wrote:
Does it do this even if the block was already in shared_buffers?
Usually not. The buffer ring algorithm is used to manage pages that are read
in specifically to satisfy a sequential scan (there's a slightly diffe
On Thu, 24 Sep 2009, Dan Sugalski wrote:
Is there any practical limit to the number of shared buffers PG 8.3.7 can
handle before more becomes counter-productive?
There are actually two distinct questions here you should consider,
because the popular wisdom here and what makes sense for your c
On Fri, Sep 25, 2009 at 8:53 AM, Scott Carey wrote:
> That won't work well anyway because the postgres shared_buffers dos not cache
> things that are sequentially scanned (it uses a ring buffer for each scan).
> So, for
> any data that is only accessed by sequential scan, you're relying on the O
* Scott Carey [090925 11:57]:
> That won't work well anyway because the postgres shared_buffers dos not cache
> things that are sequentially scanned (it uses a ring buffer for each scan).
> So, for any data that is only accessed by sequential scan, you're relying on
> the OS and the disks. If
alf Of Aidan Van Dyk
[ai...@highrise.ca]
Sent: Friday, September 25, 2009 6:33 AM
To: Dan Sugalski
Cc: Tom Lane; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PG 8.3 and large shared buffer settings
* Dan Sugalski [090925 06:06]:
> I'll have to go check, but I think it does.
* Dan Sugalski [090925 06:06]:
> I'll have to go check, but I think it does. This box hasn't actually hit
> swap since it started -- a good chunk of that RAM is used as
> semi-permanent disk cache but unfortunately the regular day-to-day use of
> this box (they won't let me have it as a dedi
At 12:36 AM -0400 9/25/09, Tom Lane wrote:
Dan Sugalski writes:
Is there any practical limit to the number of shared buffers PG 8.3.7
can handle before more becomes counter-productive?
Probably, but I've not heard any definitive measurements showing an
upper limit. The traditional wisdom o
Dan Sugalski writes:
> Is there any practical limit to the number of shared buffers PG 8.3.7
> can handle before more becomes counter-productive?
Probably, but I've not heard any definitive measurements showing an
upper limit. The traditional wisdom of limiting it to 1G or so dates
from before
15 matches
Mail list logo