Skip to content

P
Postgres FD Implementation
Commit 9a994e37 authored by Alexander Korotkov's avatar Alexander Korotkov
Browse files
Options

Fixes for vacuum_cleanup_index_scale_factor GUC option 

vacuum_cleanup_index_scale_factor was located in autovacuum group of
GUCs.  However, it affects not only autovacuum, but also manually run
VACUUM.  It appears that "client connection defaults" group of GUCs
is more appropriate for vacuum_cleanup_index_scale_factor, because
vacuum_*_age options are already located there.

Also, vacuum_cleanup_index_scale_factor was missed in
postgresql.conf.sample.  So, add it there with appropriate comment.

Author: Masahiko Sawada with minor editorization by me
Discussion: https://postgr.es/m/CAD21AoArsoXMLKudXSKN679FRzs6oubEchM53bHwn8Tp%3D2boNg%40mail.gmail.com
parent 0aa5e65a
Show whitespace changes
Inline Side-by-side
Showing with 43 additions and 45 deletions
doc/src/sgml/config.sgml
View file @ 9a994e37
......@@ -1882,50 +1882,6 @@ include_dir 'conf.d'
</note>
</sect2>
<sect2 id="runtime-config-index-vacuum">
<title>Index Vacuum</title>
<variablelist>
<varlistentry id="guc-vacuum-cleanup-index-scale-factor" xreflabel="vacuum_cleanup_index_scale_factor">
<term><varname>vacuum_cleanup_index_scale_factor</varname> (<type>floating point</type>)
<indexterm>
<primary><varname>vacuum_cleanup_index_scale_factor</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Specifies the fraction of the total number of heap tuples counted in
the previous statistics collection that can be inserted without
incurring an index scan at the <command>VACUUM</command> cleanup stage.
This setting currently applies to B-tree indexes only.
</para>
<para>
If no tuples were deleted from the heap, B-tree indexes are still
scanned at the <command>VACUUM</command> cleanup stage when at least one
of the following conditions is met: the index statistics are stale, or
the index contains deleted pages that can be recycled during cleanup.
Index statistics are considered to be stale if the number of newly
inserted tuples exceeds the <varname>vacuum_cleanup_index_scale_factor</varname>
fraction of the total number of heap tuples detected by the previous
statistics collection. The total number of heap tuples is stored in
the index meta-page. Note that the meta-page does not include this data
until <command>VACUUM</command> finds no dead tuples, so B-tree index
scan at the cleanup stage can only be skipped if the second and
subsequent <command>VACUUM</command> cycles detect no dead tuples.
</para>
<para>
The value can range from <literal>0</literal> to <literal>100</literal>.
When <varname>vacuum_cleanup_index_scale_factor</varname> is set to
<literal>0</literal>, index scans are never skipped during
<command>VACUUM</command> cleanup. The default value is <literal>0.1</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="runtime-config-resource-background-writer">
<title>Background Writer</title>
......@@ -7003,6 +6959,45 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
<varlistentry id="guc-vacuum-cleanup-index-scale-factor" xreflabel="vacuum_cleanup_index_scale_factor">
<term><varname>vacuum_cleanup_index_scale_factor</varname> (<type>floating point</type>)
<indexterm>
<primary><varname>vacuum_cleanup_index_scale_factor</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Specifies the fraction of the total number of heap tuples counted in
the previous statistics collection that can be inserted without
incurring an index scan at the <command>VACUUM</command> cleanup stage.
This setting currently applies to B-tree indexes only.
</para>
<para>
If no tuples were deleted from the heap, B-tree indexes are still
scanned at the <command>VACUUM</command> cleanup stage when at least one
of the following conditions is met: the index statistics are stale, or
the index contains deleted pages that can be recycled during cleanup.
Index statistics are considered to be stale if the number of newly
inserted tuples exceeds the <varname>vacuum_cleanup_index_scale_factor</varname>
fraction of the total number of heap tuples detected by the previous
statistics collection. The total number of heap tuples is stored in
the index meta-page. Note that the meta-page does not include this data
until <command>VACUUM</command> finds no dead tuples, so B-tree index
scan at the cleanup stage can only be skipped if the second and
subsequent <command>VACUUM</command> cycles detect no dead tuples.
</para>
<para>
The value can range from <literal>0</literal> to <literal>100</literal>.
When <varname>vacuum_cleanup_index_scale_factor</varname> is set to
<literal>0</literal>, index scans are never skipped during
<command>VACUUM</command> cleanup. The default value is <literal>0.1</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-bytea-output" xreflabel="bytea_output">
<term><varname>bytea_output</varname> (<type>enum</type>)
<indexterm>
......
src/backend/utils/misc/guc.c
View file @ 9a994e37
......@@ -3248,7 +3248,7 @@ static struct config_real ConfigureNamesReal[] =
},
{
{"vacuum_cleanup_index_scale_factor", PGC_USERSET, AUTOVACUUM,
{"vacuum_cleanup_index_scale_factor", PGC_USERSET, CLIENT_CONN_STATEMENT,
gettext_noop("Number of tuple inserts prior to index cleanup as a fraction of reltuples."),
NULL
},
......
src/backend/utils/misc/postgresql.conf.sample
View file @ 9a994e37
......@@ -575,6 +575,9 @@
#vacuum_freeze_table_age = 150000000
#vacuum_multixact_freeze_min_age = 5000000
#vacuum_multixact_freeze_table_age = 150000000
#vacuum_cleanup_index_scale_factor = 0.1 # fraction of total number of tuples
# before index cleanup, 0 always performs
# index cleanup
#bytea_output = 'hex' # hex, escape
#xmlbinary = 'base64'
#xmloption = 'content'
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment