On Tue, Feb 3, 2015 at 7:31 AM, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
