From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, <testperf-general(at)pgfoundry(dot)org> |
Subject: | Re: First set of OSDL Shared Mem scalability results, some |
Date: | 2004-10-10 21:48:48 |
Message-ID: | Pine.LNX.4.44.0410102340370.19886-100000@zigo.dhs.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Fri, 8 Oct 2004, Josh Berkus wrote:
> As you can see, the "sweet spot" appears to be between 5% and 10% of RAM,
> which is if anything *lower* than recommendations for 7.4!
What recommendation is that? To have shared buffers being about 10% of the
ram sounds familiar to me. What was recommended for 7.4? In the past we
used to say that the worst value is 50% since then the same things might
be cached both by pg and the os disk cache.
Why do we excpect the shared buffer size sweet spot to change because of
the new arc stuff? And why would it make it better to have bigger shared
mem?
Wouldn't it be the opposit, that now we don't invalidate as much of the
cache for vacuums and seq. scan so now we can do as good caching as
before but with less shared buffers.
That said, testing and getting some numbers of good sizes for shared mem
is good.
--
/Dennis Björklund
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-10-10 22:13:59 | Speeding up DELETEs on table with FKs ... |
Previous Message | Tom Lane | 2004-10-10 20:15:00 | Re: Status ofTrigger Firing Order and 'FOR EACH STATEMENT'? |
From | Date | Subject | |
---|---|---|---|
Next Message | Dawid Kuroczko | 2004-10-11 09:54:41 | Views, joins and LIMIT |
Previous Message | Gaetano Mendola | 2004-10-10 09:25:23 | Re: First set of OSDL Shared Mem scalability results, some wierdness |