> 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.
My experience from PostgreSQL on Windows: effective_cache_size should
reflect the value of "system cache" from task manager. shared_buffers (on
windows) should be rather small.
My real-workload-tests (no benchmarks, real usage of DB-Server) showed that
big shared buffers on Windows have a negative effect on PostgreSQL
performance. I have found no explanation WHY it is this way.
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
no fx, no carrier pigeon
EuroPython 2009 will take place in Birmingham - Stay tuned!
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2009-02-26 09:20:02|
|Subject: Re: Hot standby, recovery procs|
|Previous:||From: Dave Page||Date: 2009-02-26 08:47:25|
|Subject: Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)|