Joshua D. Drake wrote:
>> On Sat, 2009-02-07 at 01:52 +0100, Thomas Finneid wrote:
> This is just a hint to tell the planner how much cache will generally be
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?
>> - 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.
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
So how does this relate to WAL buffers? It seems to me that wal_buffers
are not needed. Based on the above explanation.
In response to
pgsql-performance by date
|Next:||From: Grzegorz Jaśkiewicz||Date: 2009-02-07 10:59:47|
|Subject: Re: inheritance, and plans|
|Previous:||From: Mark Wong||Date: 2009-02-07 05:46:44|
|Subject: Re: Can't locate Test/Parser/Dbt2.pm in DBT2 tests|