database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Add page-level freezing to VACUUM.

Browse Source 
Teach VACUUM to decide on whether or not to trigger freezing at the
level of whole heap pages.  Individual XIDs and MXIDs fields from tuple
headers now trigger freezing of whole pages, rather than independently
triggering freezing of each individual tuple header field.

Managing the cost of freezing over time now significantly influences
when and how VACUUM freezes.  The overall amount of WAL written is the
single most important freezing related cost, in general.  Freezing each
page's tuples together in batch allows VACUUM to take full advantage of
the freeze plan WAL deduplication optimization added by commit 9e540599.

Also teach VACUUM to trigger page-level freezing whenever it detects
that heap pruning generated an FPI.  We'll have already written a large
amount of WAL just to do that much, so it's very likely a good idea to
get freezing out of the way for the page early.  This only happens in
cases where it will directly lead to marking the page all-frozen in the
visibility map.

In most cases "freezing a page" removes all XIDs < OldestXmin, and all
MXIDs < OldestMxact.  It doesn't quite work that way in certain rare
cases involving MultiXacts, though.  It is convenient to define "freeze
the page" in a way that gives FreezeMultiXactId the leeway to put off
the work of processing an individual tuple's xmax whenever it happens to
be a MultiXactId that would require an expensive second pass to process
aggressively (allocating a new multi is especially worth avoiding here).
FreezeMultiXactId is eager when processing is cheap (as it usually is),
and lazy in the event of an individual multi that happens to require
expensive second pass processing.  This avoids regressions related to
processing of multis that page-level freezing might otherwise cause.

Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Jeff Davis <pgsql@j-davis.com>
Reviewed-By: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com
This commit is contained in:
Peter Geoghegan
2022-12-28 08:50:47 -08:00
parent 7a05425d96
commit 1de58df4fe
4 changed files with 461 additions and 295 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
doc/src/sgml/config.sgml
View File

@ -9194,9 +9194,9 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</term>
<listitem>
<para>
Specifies the cutoff age (in transactions) that <command>VACUUM</command>
should use to decide whether to freeze row versions
while scanning a table.
Specifies the cutoff age (in transactions) that
<command>VACUUM</command> should use to decide whether to
trigger freezing of pages that have an older XID.
The default is 50 million transactions. Although
users can set this value anywhere from zero to one billion,
<command>VACUUM</command> will silently limit the effective value to half
@ -9274,9 +9274,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<listitem>
<para>
Specifies the cutoff age (in multixacts) that <command>VACUUM</command>
should use to decide whether to replace multixact IDs with a newer
transaction ID or multixact ID while scanning a table. The default
is 5 million multixacts.
should use to decide whether to trigger freezing of pages with
an older multixact ID. The default is 5 million multixacts.
Although users can set this value anywhere from zero to one billion,
<command>VACUUM</command> will silently limit the effective value to half
the value of <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>,