Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? ) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
Date
Msg-id 12037.1250275044@sss.pgh.pa.us
Whole thread Raw
In response to Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> Yes. There are two ways to do the threshold:
>   1. Constant fraction of vacuum_freeze_min_age
>   2. Extra GUC

> I lean toward #1, because it avoids an extra GUC*, and it avoids the
> awkwardness when the "lower" setting is higher than the "higher"
> setting.

I tend to agree with Josh that you do need to offer two knobs.  But
expressing the second knob as a fraction (with range 0 to 1) might be
better than an independent "min" parameter.  As you say, that'd be
useful to prevent people from setting them inconsistently.

> *: As an aside, these GUCs already have incredibly confusing names, and
> an extra variable would increase the confusion. For instance, they seem
> to use "min" and "max" interchangeably.

Some of them are in fact max's, I believe.  They are complicated :-(.
It might be worth somebody taking two steps back and seeing if we need
quite so many knobs.  I think we got here partly by not wanting to
predetermine vacuuming strategies, but it doesn't help to offer
flexibility if people can't figure out how to use it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: CommitFest 2009-07: Remaining Patches
Next
From: Tom Lane
Date:
Subject: Re: Wisconsin benchmark