On Thu, Jan 20, 2022 at 11:33 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jan 20, 2022 at 11:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
> > My thinking on vacuum_freeze_min_age has shifted very slightly. I now
> > think that I'll probably need to keep it around, just so things like
> > VACUUM FREEZE (which sets vacuum_freeze_min_age to 0 internally)
> > continue to work. So maybe its default should be changed to -1, which
> > is interpreted as "whatever autovacuum_freeze_max_age/2 is". But it
> > should still be greatly deemphasized in user docs.
>
> I like that better, because it lets us retain an escape valve in case
> we should need it.
I do see some value in that, too. Though it's not going to be a way of
turning off the early freezing stuff, which seems unnecessary (though
I do still have work to do on getting the overhead for that down).
> I suggest that the documentation should say things
> like "The default is believed to be suitable for most use cases" or
> "We are not aware of a reason to change the default" rather than
> something like "There is almost certainly no good reason to change
> this" or "What kind of idiot are you, anyway?" :-)
I will admit to having a big bias here: I absolutely *loathe* these
GUCs. I really, really hate them.
Consider how we have to include messy caveats about
autovacuum_freeze_min_age when talking about
autovacuum_vacuum_insert_scale_factor. Then there's the fact that you
really cannot think about the rate of XID consumption intuitively --
it has at best a weak, unpredictable relationship with anything that
users can understand, such as data stored or wall clock time.
Then there are the problems with the equivalent MultiXact GUCs, which
somehow, against all odds, are even worse:
https://buttondown.email/nelhage/archive/notes-on-some-postgresql-implementation-details/
--
Peter Geoghegan