Re: Working on huge RAM based datasets

Martha Stewart called it a Good Thing when JanWieck@Yahoo.com (Jan Wieck) wrote:
> On 7/9/2004 10:16 AM, Merlin Moncure wrote:
>>> What is it about the buffer cache that makes it so unhappy being
>>> able to hold everything? I don't want to be seen as a cache hit
>>> fascist, but isn't it just better if the data is just *there*,
>>> available in the postmaster's address space ready for each backend
>>> process to access it, rather than expecting the Linux cache
>>> mechanism, optimised as it may be, to have to do the caching?

>> The disk cache on most operating systems is optimized.  Plus,
>> keeping shared buffers low gives you more room to bump up the sort
>> memory, which will make your big queries run faster.

> Plus, the situation will change dramatically with 7.5 where the disk
> cache will have less information than the PG shared buffers, which
> will become sequential scan resistant and will know that a block was
> pulled in on behalf of vacuum and not because the regular database
> access pattern required it.

It'll be very curious how this changes things.

I _think_ it means that shared buffer usage becomes more efficient
both for small and large buffers, since vacuums and seq scans
shouldn't "eviscerate" the shared buffers the way they can in earlier
versions.

What would be most interesting to see is whether this makes it wise to
increase shared buffer size.  It may be more effective to bump down
the cache a little, and bump up sort memory; hard to tell.
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/spreadsheets.html
"But   life  wasn't yes-no,   on-off.   Life was shades   of gray, and
rainbows not in the order of the spectrum."
-- L. E. Modesitt, Jr., _Adiamante_