Re: Simplifying replication

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 03:13:57
Message-ID: 201011120313.oAC3DvS14766@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

It is hard to believe that, for tuning, the number of 16mb files is more
meaningful then raw file size.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-11-12 04:00:13 Re: Simplifying replication
Previous Message Bruce Momjian 2010-11-12 03:01:10 Re: Exposing an installation's default value of unix_socket_directory