Horton

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-20T22:00:12Z
Lists: pgsql-hackers 
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

Commits

  1. Have VACUUM warn on relfrozenxid "in the future".

  2. vacuumlazy.c: Further consolidate resource allocation.

  3. Generalize how VACUUM skips all-frozen pages.

  4. Set relfrozenxid to oldest extant XID seen by VACUUM.

  5. Doc: Add relfrozenxid Tip to XID wraparound section.

  6. vacuumlazy.c: document vistest and OldestXmin.

  7. Increase hash_mem_multiplier default to 2.0.

  8. Consolidate VACUUM xid cutoff logic.

  9. Add VACUUM instrumentation for scanned pages, relfrozenxid.

  10. Simplify lazy_scan_heap's handling of scanned pages.

  11. Try to stabilize reloptions test, again.

  12. Unify VACUUM VERBOSE and autovacuum logging.

  13. Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.

  14. pg_resetxlog: add option to set oldest xid & use by pg_upgrade

  15. Teach VACUUM to bypass unnecessary index vacuuming.

  16. Centralize horizon determination for temp tables, fixing bug due to skew.

  17. pg_surgery: Try to stabilize regression tests.

  18. Add "split after new tuple" nbtree optimization.

  19. Fix bugs in vacuum of shared rels, by keeping their relcache entries current.

  20. Avoid useless truncation attempts during VACUUM.

  21. Only skip pages marked as clean in the visibility map, if the last 32

  22. Fix recently-understood problems with handling of XID freezing, particularly