From: | Harald Armin Massa <chef(at)ghum(dot)de> |
---|---|
To: | Greg Stark <stark(at)enterprisedb(dot)com> |
Cc: | jd(at)commandprompt(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: effective_cache_size less than shared_buffers |
Date: | 2009-02-26 09:14:55 |
Message-ID: | e3e180dc0902260114q2a350dbax5aa65fd3345e694b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg,
>
> 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.
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-02-26 09:20:02 | Re: Hot standby, recovery procs |
Previous Message | Dave Page | 2009-02-26 08:47:25 | Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules) |