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: | Raw Message | Whole Thread | 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 |