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 eager and lazy freezing strategies to VACUUM.

Browse Source 
Eager freezing strategy avoids large build-ups of all-visible pages.  It
makes VACUUM trigger page-level freezing whenever doing so will enable
the page to become all-frozen in the visibility map.  This is useful for
tables that experience continual growth, particularly strict append-only
tables such as pgbench's history table.  Eager freezing significantly
improves performance stability by spreading out the cost of freezing
over time, rather than doing most freezing during aggressive VACUUMs.
It complements the insert autovacuum mechanism added by commit b07642db.

VACUUM determines its freezing strategy based on the value of the new
vacuum_freeze_strategy_threshold GUC (or reloption) with logged tables.
Tables that exceed the size threshold use the eager freezing strategy.
Unlogged tables and temp tables always use eager freezing strategy,
since the added cost is negligible there.  Non-permanent relations won't
incur any extra overhead in WAL written (for the obvious reason), nor in
pages dirtied (since any extra freezing will only take place on pages
whose PD_ALL_VISIBLE bit needed to be set either way).

VACUUM uses lazy freezing strategy for logged tables that fall under the
GUC size threshold.  Page-level freezing triggers based on the criteria
established in commit 1de58df4, which added basic page-level freezing.

Eager freezing is strictly more aggressive than lazy freezing.  Settings
like vacuum_freeze_min_age still get applied in just the same way in
every VACUUM, independent of the strategy in use.  The only mechanical
difference between eager and lazy freezing strategies is that only the
former applies its own additional criteria to trigger freezing pages.
Note that even lazy freezing strategy will trigger freezing whenever a
page happens to have required that an FPI be written during pruning,
provided that the page will thereby become all-frozen in the visibility
map afterwards (due to the FPI optimization from commit 1de58df4).

The vacuum_freeze_strategy_threshold default setting is 4GB.  This is a
relatively low setting that prioritizes performance stability.  It will
be reviewed at the end of the Postgres 16 beta period.

Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Jeff Davis <pgsql@j-davis.com>
Reviewed-By: Andres Freund <andres@anarazel.de>
Reviewed-By: Matthias van de Meent <boekewurm+postgres@gmail.com>
Discussion: https://postgr.es/m/CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com
This commit is contained in:
Peter Geoghegan
2023-01-25 14:15:38 -08:00
parent 642e8821d7
commit 4d41799261
12 changed files with 197 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -9272,6 +9272,36 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
<varlistentry id="guc-vacuum-freeze-strategy-threshold" xreflabel="vacuum_freeze_strategy_threshold">
<term><varname>vacuum_freeze_strategy_threshold</varname> (<type>integer</type>)
<indexterm>
<primary><varname>vacuum_freeze_strategy_threshold</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Specifies the cutoff storage size that
<command>VACUUM</command> should use to determine its freezing
strategy. This is applied by comparing it to the size of the
target table's <glossterm linkend="glossary-fork">main
fork</glossterm> at the beginning of each <command>VACUUM</command>.
Eager freezing strategy is used by <command>VACUUM</command>
when the table's main fork size exceeds this value.
<command>VACUUM</command> <emphasis>always</emphasis> uses
eager freezing strategy when processing <glossterm
linkend="glossary-unlogged">unlogged</glossterm> tables,
regardless of this setting. Otherwise <command>VACUUM</command>
uses lazy freezing strategy. For more information see <xref
linkend="vacuum-for-wraparound"/>.
</para>
<para>
If this value is specified without units, it is taken as
megabytes. The default is four gigabytes
(<literal>4GB</literal>).
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-vacuum-failsafe-age" xreflabel="vacuum_failsafe_age">
<term><varname>vacuum_failsafe_age</varname> (<type>integer</type>)
<indexterm>

50
doc/src/sgml/maintenance.sgml
View File

@ -478,13 +478,30 @@
</note>
<para>
<xref linkend="guc-vacuum-freeze-min-age"/>
controls how old an XID value has to be before rows bearing that XID will be
frozen. Increasing this setting may avoid unnecessary work if the
rows that would otherwise be frozen will soon be modified again,
but decreasing this setting increases
the number of transactions that can elapse before the table must be
vacuumed again.
<xref linkend="guc-vacuum-freeze-strategy-threshold"/> controls
<command>VACUUM</command>'s freezing strategy. The
<firstterm>eager freezing strategy</firstterm> makes
<command>VACUUM</command> freeze all rows on a page whenever each
and every row on the page is considered visible to all current
transactions (immediately after dead row versions are removed).
Freezing pages early and in batch often spreads out the overhead
of freezing over time. <command>VACUUM</command> consistently
avoids allowing unfrozen all-visible pages to build up, improving
system level performance stability. The <firstterm>lazy freezing
strategy</firstterm> makes <command>VACUUM</command> determine
whether pages should be frozen on the basis of the age of the
oldest XID on the page. Freezing pages lazily sometimes avoids
the overhead of freezing that turns out to have been unnecessary
because the rows were modified soon after freezing took place.
</para>
<para>
<xref linkend="guc-vacuum-freeze-min-age"/> controls how old an
XID value has to be before pages with rows bearing that XID are
frozen. This setting is an additional trigger criteria for
freezing a page's tuples. It is used by both freezing strategies,
though it typically has little impact when <command>VACUUM</command>
uses the eager freezing strategy.
</para>
<para>
@ -506,12 +523,21 @@
always use its aggressive strategy.
</para>
<para>
Controlling the overhead of freezing existing all-visible pages
during aggressive vacuuming is the goal of the eager freezing
strategy. Increasing <varname>vacuum_freeze_strategy_threshold</varname>
may avoid unnecessary work, but it increases the risk of an
eventual aggressive vacuum that performs an excessive amount of
<quote>catch up</quote> freezing all at once.
</para>
<para>
The maximum time that a table can go unvacuumed is two billion
transactions minus the <varname>vacuum_freeze_min_age</varname> value at
the time of the last aggressive vacuum. If it were to go
unvacuumed for longer than
that, data loss could result. To ensure that this does not happen,
unvacuumed for longer than that, the system could temporarily refuse to
allocate new transaction IDs. To ensure that this never happens,
autovacuum is invoked on any table that might contain unfrozen rows with
XIDs older than the age specified by the configuration parameter <xref
linkend="guc-autovacuum-freeze-max-age"/>. (This will happen even if
@ -551,7 +577,7 @@
</para>
<para>
The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</varname>
One disadvantage of increasing <varname>autovacuum_freeze_max_age</varname>
(and <varname>vacuum_freeze_table_age</varname> along with it) is that
the <filename>pg_xact</filename> and <filename>pg_commit_ts</filename>
subdirectories of the database cluster will take more space, because it
@ -837,8 +863,8 @@ vacuum insert threshold = vacuum base insert threshold + vacuum insert scale fac
For tables which receive <command>INSERT</command> operations but no or
almost no <command>UPDATE</command>/<command>DELETE</command> operations,
it may be beneficial to lower the table's
<xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow
tuples to be frozen by earlier vacuums. The number of obsolete tuples and
<xref linkend="reloption-autovacuum-freeze-strategy-threshold"/>
to allow freezing to take place proactively. The number of obsolete tuples and
the number of inserted tuples are obtained from the cumulative statistics system;
it is a semi-accurate count updated by each <command>UPDATE</command>,
<command>DELETE</command> and <command>INSERT</command> operation. (It is

14
doc/src/sgml/ref/create_table.sgml
View File

@ -1781,6 +1781,20 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
</listitem>
</varlistentry>
<varlistentry id="reloption-autovacuum-freeze-strategy-threshold" xreflabel="autovacuum_freeze_strategy_threshold">
<term><literal>autovacuum_freeze_strategy_threshold</literal>, <literal>toast.autovacuum_freeze_strategy_threshold</literal> (<type>integer</type>)
<indexterm>
<primary><varname>autovacuum_freeze_strategy_threshold</varname> storage parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Per-table value for <xref linkend="guc-vacuum-freeze-strategy-threshold"/>
parameter.
</para>
</listitem>
</varlistentry>
<varlistentry id="reloption-log-autovacuum-min-duration" xreflabel="log_autovacuum_min_duration">
<term><literal>log_autovacuum_min_duration</literal>, <literal>toast.log_autovacuum_min_duration</literal> (<type>integer</type>)
<indexterm>