On Thu, Feb 26, 2009 at 1:33 AM, Joshua D. Drake <j...@commandprompt.com> wrote: > > On Wed, 2009-02-25 at 17:04 -0800, Josh Berkus wrote: > >> Joshua D. Drake wrote: >> >> > I would say no. Although I could see an argument for the default >> > effective_cache_size always being the same size as shared_buffers. >> >> That's certainly not what we've meant historically by ECS.
> Since we are already using X amount > of shared_buffers we know we have at least X amount of cache. That's not what you wrote, at least how it was understood. It sounds like you're in violent agreement. > We can't determine the size of the FS cache. Hence why we have the parameter. > We can determine the size > of the shared_buffers. The idea here is to eliminate one of those by > default PostgreSQL is slow issues. Well we won't eliminate any problems unless we actually override the effective_cache_size setting by clipping it to shared_buffers. I don't really see much of a problem doing that. The only case where that would annoy someone was if they're intentionally understating effective_cache_size to push the planner into avoiding nested loops and I doin't think it's a powerful enough knob to be very likely used that way. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
