On Tue, Feb 3, 2015 at 7:31 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 02/02/2015 03:36 PM, Robert Haas wrote:
>> Second, I*think* that these settings are symmetric and, if that's
>> right, then I suggest that they ought to be named symmetrically.
>> Basically, I think you've got min_checkpoint_segments (the number of
>> recycled segments we keep around always) and max_checkpoint_segments
>> (the maximum number of segments we can have between checkpoints),
>> essentially splitting the current role of checkpoint_segments in half.
>> I'd go so far as to suggest we use exactly that naming. It would be
>> reasonable to allow the value to be specified in MB rather than in
>> 16MB units, and to specify it that way by default, but maybe a
>> unit-less value should have the old interpretation since everybody's
>> used to it. That would require adding GUC_UNIT_XSEG or similar, but
>> that seems OK.
>
> Works for me. However, note that "max_checkpoint_segments = 10" doesn't mean
> the same as current "checkpoint_segments = 10". With checkpoint_segments =
> 10 you end up with about 2x-3x as much WAL as with max_checkpoint_segments =
> 10. So the "everybody's used to it" argument doesn't hold much water.
Hmm, that's surprising. Why does that happen?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
