On Thu, 2011-05-26 at 09:31 -0500, Merlin Moncure wrote:
> Where they are most helpful is for masking of i/o if
> a page gets dirtied >1 times before it's written out to the heap
Another possible benefit of higher shared_buffers is that it may reduce
WAL flushes. A page cannot be evicted from shar
On 27/05/11 11:10, Greg Smith wrote:
OK, so the key thing to do is create a table such that shared_buffers
is smaller than the primary key index on a table, then UPDATE that
table furiously. This will page constantly out of the buffer cache to
the OS one, doing work that could be avoided. I
On 28/05/11 02:38, Kevin Grittner wrote:
Mark Kirkwood wrote:
Battery Pack Missing : No
Fully Charged : Yes
Initialized : Yes
I'm not familiar with that output (I leave that to the hardware
guys), but it sure looks like there's a battery there. The
On Fri, May 27, 2011 at 9:24 PM, Maciek Sakrejda wrote:
> Another +1. While I understand that this is not simple, many users
> will not look outside of standard docs, especially when first
> evaluating PostgreSQL. Merlin is right that the current wording does
> not really mention a down side to cr
>> After failing to get even basic good recommendations for
>> checkpoint_segments into the docs, I completely gave up on focusing there as
>> my primary way to spread this sort of information.
>
> Hmm. That's rather unfortunate. +1 for revisiting that topic, if you
> have the energy for it.
An
On Fri, May 27, 2011 at 2:47 PM, Greg Smith wrote:
> Any attempt to make a serious change to the documentation around performance
> turns into a bikeshedding epic, where the burden of proof to make a change
> is too large to be worth the trouble to me anymore. I first started
> publishing tuning
On Fri, May 27, 2011 at 1:47 PM, Greg Smith wrote:
> Merlin Moncure wrote:
>>
>> That's just plain unfair: I didn't challenge your suggestion nor give
>> you homework.
>
> I was stuck either responding to your challenge, or leaving the impression I
> hadn't done the research to back the suggestion
Merlin Moncure wrote:
That's just plain unfair: I didn't challenge your suggestion nor give
you homework.
I was stuck either responding to your challenge, or leaving the
impression I hadn't done the research to back the suggestions I make if
I didn't. That made it a mandatory homework assign
Scott Carey wrote:
And there is an OS component to it too. You can actually get away with
shared_buffers at 90% of RAM on Solaris. Linux will explode if you try
that (unless recent kernels have fixed its shared memory accounting).
You can use much larger values for shared_buffers on Solari
Scott Carey wrote:
> So how far do you go? 128MB? 32MB? 4MB?
Under 8.2 we had to keep shared_buffers less than the RAM on our BBU
RAID controller, which had 256MB -- so it worked best with
shared_buffers in the 160MB to 200MB range. With 8.3 we found that
anywhere from 512MB to 1GB perform
So how far do you go? 128MB? 32MB? 4MB?
Anecdotal and an assumption, but I'm pretty confident that on any server
with at least 1GB of dedicated RAM, setting it any lower than 200MB is not
even going to help latency (assuming checkpoint and log configuration is
in the realm of sane, and connecti
On Thu, May 26, 2011 at 6:10 PM, Greg Smith wrote:
> Merlin Moncure wrote:
>>
>> So, the challenge is this: I'd like to see repeatable test cases that
>> demonstrate regular performance gains > 20%. Double bonus points for
>> cases that show gains > 50%.
>
> Do I run around challenging your sugge
Mark Kirkwood wrote:
>Battery Pack Missing : No
>Fully Charged : Yes
>Initialized : Yes
I'm not familiar with that output (I leave that to the hardware
guys), but it sure looks like there's a battery there. The one
thing I didn't see is whether it
On 27/05/2011 00:34, Tory M Blue wrote:
Working on some optimization as well as finally getting off my
backside and moving us to 64bit (32gb+memory).
I was reading and at some point it appears on freeBSD the Postgres
block size was upped to 16kb, from 8kb. And on my fedora systems I
believe the
14 matches
Mail list logo
