On Mon, 2007-06-25 at 01:33 -0400, Greg Smith wrote:
> On Sun, 24 Jun 2007, Simon Riggs wrote:
>
> > Greg can't choose to use checkpoint_segments as the limit and then
> > complain about unbounded recovery time, because that was clearly a
> > conscious choice.
>
> I'm complaining
I apologise for using that emotive phrase.
> only because everyone seems content to wander in a
> direction where the multiplier on checkpoint_segments for how many
> segments are actually active at once will go up considerably, which can
> make a known problem (recovery time) worse.
+50% more. Recovery time is a consideration that can be adjusted for. We
have done nothing to make recovery rate worse; the additional WAL leads
to an increased recovery time *only* if you keep the same parameter
settings. There is no reason to keep them the same, nor do we promise
that parameters will keep the exact meaning they had previous releases.
As you say, we can put comments in the release notes to advise people of
50% increase in recovery time if the parameters stay the same. That
would be balanced by the comment that checkpoints are now considerably
smoother than before and more frequent checkpoints are unlikely to be a
problem, so it is OK to reduce the parameters from the settings you used
in previous releases.
I don't see any reason why we would want unsmooth checkpoints; similarly
we don't want unsmooth bg writing, unsmooth archiving etc.. Performance
will increase, response times will drop and people will be happy.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com