Naomi Walker wrote:
> From my many years of Informix knowledge, we noticed that checkpoints,
> during high activity times, did take a long time, because it locked the
> shared memory segment. We found that setting the checkpoint knobs to flush
> almost constantly, overall, was much better for performance.
>
> Looking in postgresql.conf, it seems that some tweaking of :
> CHECKPOINT_SEGMENTS and CHECKPOINT_TIMEOUT are in order.
>
> I also see some interesting items in the WAL_* configuration parameters,
> and would look at these as well. Again, in Informix-speak, we were able to
> control when the buffers flushed to disk, with parameters like:
> Start flushing buffers when they are X% full
> and keep flushing until they are X% full
>
> Overall, having TONS of buffers helped benchmark performance, but could
> have slowed down checkpoints had we not continually flushed to disk.
Actually, we don't lock shared memory like Informix does. As I
remember, other backends can write to the WAL while we are doing the
checkpoint. In fact, there is code in there that expects the WAL file
may grow during checkpointing.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026