Skip site navigation (1) Skip section navigation (2)

Re: explanation of some configs

From: Thomas Finneid <tfinneid(at)fcon(dot)no>
To: jd(at)commandprompt(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: explanation of some configs
Date: 2009-02-07 09:27:34
Message-ID: 498D5406.2050606@fcon.no (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Grzegorz JaƛkiewiczDate: 2009-02-07 10:59:47
Subject: Re: inheritance, and plans
Previous:From: Mark WongDate: 2009-02-07 05:46:44
Subject: Re: Can't locate Test/Parser/Dbt2.pm in DBT2 tests

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group