| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: archive_timeout? |
| Date: | 2006-10-10 18:17:57 |
| Message-ID: | 673.1160504277@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Maybe I just don't understand checkpoint timeout? Could it reasonably be
> set to something like 12 hours? I can't think why not, but the config
> default is 5 minutes, so I would be hesitant to change it by that much.
The only constraining factor on it is how much WAL data are you willing
to replay in order to recover from a crash. If you've got a low-volume
database then replaying up to 12 hours' worth of activity might not be
unacceptable. Also, if you have spikes of activity, then
checkpoint_segments would kick in after a spike had generated X amount
of data. So I don't see any strong reason why it couldn't be set much
higher than archive_timeout.
Now the other side of the coin is that if you do have a steady low level
of activity then a small archive_timeout is still going to result in
shipping lots of partially-filled WAL files. Compression might help
some, but the bottom line is simply that archive_timeout isn't an
efficient mechanism for dealing with low-volume databases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashish Goel | 2006-10-10 18:32:33 | postgres database crashed |
| Previous Message | Merlin Moncure | 2006-10-10 18:16:19 | Re: more anti-postgresql FUD |