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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
