Re: explanation of some configs
От | Thomas Finneid |
---|---|
Тема | Re: explanation of some configs |
Дата | |
Msg-id | 498D5406.2050606@fcon.no обсуждение исходный текст |
Ответ на | Re: explanation of some configs ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: explanation of some configs
Re: explanation of some configs |
Список | 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
В списке pgsql-performance по дате отправления: