Re: doc fixes: vacuum_cleanup_index_scale_factor - Mailing list pgsql-hackers

From Robert Haas
Subject Re: doc fixes: vacuum_cleanup_index_scale_factor
Date
Msg-id CA+TgmoY7bDLf=YzGk_RugqKygqLs86KZnKKfE2mm5Yy-c1Dq3Q@mail.gmail.com
Whole thread Raw
In response to doc fixes: vacuum_cleanup_index_scale_factor  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: doc fixes: vacuum_cleanup_index_scale_factor
List pgsql-hackers
On Tue, May 1, 2018 at 10:30 PM, Justin Pryzby <pryzby@telsasoft.com> wrote:
> -        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.  First, if a B-tree index contains no deleted pages
> +        which can be recycled during cleanup.  Second, if B-tree
> +        index statistics are not stale.  Index statistics are considered stale unless
> +        <varname>vacuum_cleanup_index_scale_factor</varname> is non-negative, 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, meaning index scan during cleanup is not skipped.

I agree that this documentation needs to be rewritten but your rewrite
doesn't strike me as very good English either.  A sentence of the form
"First, if I like hamburgers." is not correct English.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: lingering references to V0 calling convention
Next
From: Robert Haas
Date:
Subject: Re: Explain buffers wrong counter with parallel plans