Joshua D. Drake wrote:
On Sat, 2009-02-07 at 01:52 +0100, Thomas Finneid wrote:
>>
effective_cache_size
>>
This is just a hint to tell the planner how much cache will generally be
available.
ok, but available for what?
The number should be reflective of your shared buffers +
available operating system cache. If you database is postgresql only you
can generally set this very high 75% of available ram. If not then you
need to tone it down.
So that means, if I have 8GB ram and have set shared buffer to e.g. 4GB,
I should set the effective_cache_size to at least 4GB otherwise the
planner will assume I dont have as much memory available so it would be
sort of pointless so set shared_buffer to 4GB?
checkpoint_segments
- specifies the number of segments?
The number of segments that will be used before a checkpoint is forced.
So to sum it up:
- Specifies the number of memory segments the WAL will use before a
checkpoint occur. (A checkpoint guarantees the data has been written to
disk, including dirty pages.)
- A segment is 16MB and the number of actually used segments are dynamic.
- If this number is too low or the transaction is large, PG will spend
more time on performing checkpoint operations which decreases performance.
Q1:
So checkpoint_time is then just another way of expressing the same?
I.e. to ensure that if the segments have not been filled, which would
foce a checkpoint, a checkpoint is at least forced at the specified time
lapse?
Q2:
So how does this relate to WAL buffers? It seems to me that wal_buffers
are not needed. Based on the above explanation.
regards
thomas
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
