8000 Add page-level freezing to VACUUM. · postgres/postgres@1de58df · GitHub
[go: up one dir, main page]
Skip to content

Commit 1de58df

Browse files
petergeogheganpetergeoghegan
committed
Add page-level freezing to VACUUM.
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 9e54059. 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
1 parent 7a05425 commit 1de58df

File tree

4 files changed

+463
-297
lines changed

4 files changed

+463
-297
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -9194,9 +9194,9 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
91949194
</term>
91959195
<listitem>
91969196
<para>
9197-
Specifies the cutoff age (in transactions) that <command>VACUUM</command>
9198-
should use to decide whether to freeze row versions
9199-
while scanning a table.
9197+
Specifies the cutoff age (in transactions) that
9198+
<command>VACUUM</command> should use to decide whether to
9199+
trigger freezing of pages that have an older XID.
92009200
The default is 50 million transactions. Although
92019201
users can set this value anywhere from zero to one billion,
92029202
<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;
92749274
<listitem>
92759275
<para>
92769276
Specifies the cutoff age (in multixacts) that <command>VACUUM</command>
9277-
should use to decide whether to replace multixact IDs with a newer
9278-
transaction ID or multixact ID while scanning a table. The default
9279-
is 5 million multixacts.
9277+
should use to decide whether to trigger freezing of pages with
9278+
an older multixact ID. The default is 5 million multixacts.
92809279
Although users can set this value anywhere from zero to one billion,
92819280
<command>VACUUM</command> will silently limit the effective value to half
92829281
the value of <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>,

0 commit comments

Comments
 (0)
0