From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Simplifying replication |
Date: | 2010-11-12 14:05:02 |
Message-ID: | 201011121405.oACE52v27305@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Thu, Nov 11, 2010 at 10:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Robert Haas wrote:
> >> On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> >
> >> >> I sort of agree with you that the current checkpoint_segments
> >> >> parameter is a bit hard to tune, at least if your goal is to control
> >> >> the amount of disk space that will be used by WAL files. ?But I'm not
> >> >> sure your proposal is better. ?Instead of having a complicated formula
> >> >> for predicting how much disk space would get used by a given value for
> >> >> checkpoint_segments, we'd have a complicated formula for the amount of
> >> >> WAL that would force a checkpoint based on max_wal_size.
> >> >
> >> > Yes, but the complicated formula would then be *in our code* instead of
> >> > being inflicted on the user, as it now is.
> >>
> >> I don't think so - I think it will just be inflicted on the user in a
> >> different way. ?We'd still have to document what the formula is,
> >> because people will want to understand how often a checkpoint is going
> >> to get forced.
> >>
> >> So here's an example of how this could happen. ?Someone sets
> >> max_wal_size = 480MB. ?Then, they hear about the
> >> checkpoint_completion_target parameter, and say, ooh, goody, let me
> >> boost that. ?So they raise it from 0.5 to 0.9. ?Now, all of a sudden,
> >> they're getting more frequent checkpoints. ?Performance may get worse
> >
> > Uh, checkpoint_completion_target only controls flushing of buffers
> > between checkpoints, not the frequency of checkpoints.
>
> According to the formula in our fine documentation, if you increase
> checkpoint_completion_target, the maximum number of WAL files also
> increases. This makes sense: the files from the last checkpoint can't
> be removed until further along into the next cycle. Therefore, if you
> wanted to increase the checkpoint_completion_target while keeping the
> maximum amount of WAL on disk the same, you'd need to trigger
> checkpoints more frequently.
Do we recycle WAL files between checkpoints or just at checkpoint time?
I thought it was only at checkpoint time.
Also, there was talk that a larger WAL directory would slow recovery,
but I thought it was only the time since the last checkpoint that
controlled that.
[ Again, sorry for my late reading of this and other threads. ]
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2010-11-12 14:07:27 | Re: multi-platform, multi-locale regression tests |
Previous Message | Bruce Momjian | 2010-11-12 14:02:40 | Re: duplicate connection failure messages |