Re: New strategies for freezing, advancing relfrozenxid early
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>,
John Naylor <john.naylor@enterprisedb.com>, Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-27T03:01:03Z
Lists: pgsql-hackers
On Thu, Jan 26, 2023 at 6:37 PM Andres Freund <andres@anarazel.de> wrote: > I also don't really see how that is responsive to anything else in my > email. That's just as true for the current gating condition (the issuance of > an FPI during heap_page_prune() / HTSV()). > > What I was wondering about is whether we should replace the > fpi_before != pgWalUsage.wal_fpi > with > records_before != pgWalUsage.wal_records && !WouldIssueFpi(page) I understand that. What I'm saying is that that's going to create a huge problem of its own, unless you separately account for that problem. The simplest and obvious example is something like a pgbench_tellers table. VACUUM will generally run fast enough relative to the workload that it will set some of those pages all-visible. Now it's going to freeze them, too. Arguably it shouldn't even be setting the pages all-visible, but now you make that existing problem much worse. The important point is that there doesn't seem to be any good way around thinking about the table as a whole if you're going to freeze speculatively. This is not the same dynamic as we see with the FPI thing IMV -- that's not nearly so speculative as what you're talking about, since it is speculative in roughly the same sense that eager freezing was speculative (hence the suggestion that something like vacuum_freeze_strategy_threshold could have a roll to play). The FPI thing is mostly about the cost now versus the cost later on. You're gambling that you won't get another FPI later on if you freeze now. But the cost of a second FPI later on is so much higher than the added cost of freezing now that that's a very favorable bet, that we can afford to "lose" many times while still coming out ahead overall. And even when we lose, you generally still won't have been completely wrong -- even then there generally will indeed be a second FPI later on for the same page, to go with everything else. This makes the wasted freezing even less significant, on a comparative basis! It's also likely true that an FPI in lazy_scan_prune is a much stronger signal, but I think that the important dynamic is that we're reasoning about "costs now vs costs later on". The asymmetry is really important. -- Peter Geoghegan
Commits
-
Revert "Add eager and lazy freezing strategies to VACUUM."
- 6c6b49726644 16.0 landed
-
Add eager and lazy freezing strategies to VACUUM.
- 4d4179926139 16.0 landed
-
Refine the definition of page-level freezing.
- b37a08323964 16.0 landed
-
Avoid special XID snapshotConflictHorizon values.
- 6daeeb1f9196 16.0 cited
-
Add page-level freezing to VACUUM.
- 1de58df4fec7 16.0 landed
-
Remove overzealous MultiXact freeze assertion.
- 63c844a0a5d7 16.0 landed
-
Refactor how VACUUM passes around its XID cutoffs.
- 4ce3afb82ecf 16.0 landed
-
Deduplicate freeze plans in freeze WAL records.
- 9e5405993c1e 16.0 cited
-
Set relfrozenxid to oldest extant XID seen by VACUUM.
- 0b018fabaaba 15.0 cited
-
Only skip pages marked as clean in the visibility map, if the last 32
- bf136cf6e376 8.4.0 cited
-
Add vacuum_freeze_table_age GUC option, to control when VACUUM should
- 6587818542e7 8.4.0 cited