Re: doc fixes: vacuum_cleanup_index_scale_factor - Mailing list pgsql-hackers
| From | Alexander Korotkov |
|---|---|
| Subject | Re: doc fixes: vacuum_cleanup_index_scale_factor |
| Date | |
| Msg-id | CAPpHfdv5roC_PR52sUzCtoc+yuhdDji9t_Ptv6zAFtt5Dc+XGA@mail.gmail.com Whole thread Raw |
| In response to | Re: doc fixes: vacuum_cleanup_index_scale_factor (Justin Pryzby <pryzby@telsasoft.com>) |
| Responses |
Re: doc fixes: vacuum_cleanup_index_scale_factor
|
| List | pgsql-hackers |
Hi!
Thank you for your attention on this subject. It's definitely right,
that documentation needs to be revised in these places.
On Wed, May 2, 2018 at 6:43 PM, Justin Pryzby <pryzby@telsasoft.com> wrote:
index eabe2a9..e305de9 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1893,14 +1893,16 @@ include_dir 'conf.d'
</term>
<listitem>
<para>
- When no tuples were deleted from the heap, B-tree indexes might still
- be scanned during <command>VACUUM</command> cleanup stage by two
- reasons. The first reason is that B-tree index contains deleted pages
- which can be recycled during cleanup. The second reason is that B-tree
- index statistics is stalled. The criterion of stalled index statistics
- is number of inserted tuples since previous statistics collection
- is greater than <varname>vacuum_cleanup_index_scale_factor</varname>
- fraction of total number of heap tuples.
+ When no tuples were deleted from the heap, B-tree indexes are still
+ scanned during <command>VACUUM</command> cleanup stage unless two
+ conditions are met: the index contains no deleted pages which can be
+ recycled during cleanup; and, the index statistics are not stale.
+ Index statistics are considered stale unless
+ <varname>vacuum_cleanup_index_scale_factor</varname>
+ is set to a non-negative value, and the number of inserted tuples since
+ the previous statistics collection is less than that fraction of the
+ total number of heap tuples. The default is -1, which means index
+ scans during <command>VACUUM</command> cleanup are not skipped.</para>
</listitem>
</varlistentry>
The default value of vacuum_cleanup_index_scale_
that means that 10% of tuples need to be inserted in order to trigger
vacuum cleanup. See guc.c
{
{"vacuum_cleanup_index_scale_
gettext_noop("Number of tuple inserts prior to index cleanup as a fraction of reltuples."),
NULL
},
&vacuum_cleanup_index_scale_
0.1, 0.0, 100.0,
NULL, NULL, NULL
},
Default value of vacuum_cleanup_index_scale_
it means that by default value of vacuum_cleanup_index_scale_
is used. See following piece of code in _bt_vacuum_needs_cleanup().
cleanup_scale_factor = (relopts &&
relopts->vacuum_cleanup_index_
? relopts->vacuum_cleanup_index_
: vacuum_cleanup_index_scale_
In order to have vacuum cleanup scan every time, one should set
vacuum_cleanup_index_scale_
we need to replace "cleanup_scale_factor < 0" to
"cleanup_scale_factor <= 0" in the following condition:
if (cleanup_scale_factor < 0 ||
metad->btm_last_cleanup_num_
info->num_heap_tuples > (1.0 + cleanup_scale_factor) *
metad->btm_last_cleanup_num_
result = true;
Another issue is that we by default store -1 in
metad->btm_last_cleanup_num_
of meta-page rewrite. metad->btm_last_
set at first btcleanup() call when no tuples were deleted. Second and
subsequent btcleanup() calls may skip index scan. This aspect needs
to be properly documented.
I'm going to propose a patch for this subject in a couple of days.
That patch would incorporate some of your changes as well as contain
some changes from me.
------
Alexander Korotkov
Postgres Professional: http://www.
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.
The Russian Postgres Company
pgsql-hackers by date: