Re: PG 14 release notes, first draft - Mailing list pgsql-hackers

On Tue, May 18, 2021 at 11:07 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, May 18, 2021 at 06:28:49PM +0900, Masahiko Sawada wrote:
> > On Mon, May 10, 2021 at 3:03 PM Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes.  You can
> > > see the most current  build of them here:
> > >
> > >         https://momjian.us/pgsql_docs/release-14.html
> > >
> >
> > I think we need to mention in the release note that
> > vacuum_cleanup_index_scale_factor GUC parameter has been removed and
> > vacuum_cleanup_index_scale_factor storage parameter has been
> > deprecated (please refer to commit 9f3665fb and effdd3f3b63).
>
> Looking at the full commit message:
>
>         commit 9f3665fbfc
>         Author: Peter Geoghegan <pg@bowt.ie>
>         Date:   Wed Mar 10 16:27:01 2021 -0800
>
>             Don't consider newly inserted tuples in nbtree VACUUM.
>
>             Remove the entire idea of "stale stats" within nbtree VACUUM (stop
>             caring about stats involving the number of inserted tuples).  Also
>             remove the vacuum_cleanup_index_scale_factor GUC/param on the master
>             branch (though just disable them on postgres 13).
>
>             The vacuum_cleanup_index_scale_factor/stats interface made the nbtree AM
>             partially responsible for deciding when pg_class.reltuples stats needed
>             to be updated.  This seems contrary to the spirit of the index AM API,
>             though -- it is not actually necessary for an index AM's bulk delete and
>             cleanup callbacks to provide accurate stats when it happens to be
>             inconvenient.  The core code owns that.  (Index AMs have the authority
>             to perform or not perform certain kinds of deferred cleanup based on
>             their own considerations, such as page deletion and recycling, but that
>             has little to do with pg_class.reltuples/num_index_tuples.)
>
>             This issue was fairly harmless until the introduction of the
>             autovacuum_vacuum_insert_threshold feature by commit b07642db, which had
>             an undesirable interaction with the vacuum_cleanup_index_scale_factor
>             mechanism: it made insert-driven autovacuums perform full index scans,
>             even though there is no real benefit to doing so.  This has been tied to
>             a regression with an append-only insert benchmark [1].
>
>             Also have remaining cases that perform a full scan of an index during a
>             cleanup-only nbtree VACUUM indicate that the final tuple count is only
>             an estimate.  This prevents vacuumlazy.c from setting the index's
>             pg_class.reltuples in those cases (it will now only update pg_class when
>             vacuumlazy.c had TIDs for nbtree to bulk delete).  This arguably fixes
>             an oversight in deduplication-related bugfix commit 48e12913.
>
>             [1] https://smalldatum.blogspot.com/2021/01/insert-benchmark-postgres-is-still.html
>
>             Author: Peter Geoghegan <pg@bowt.ie>
>             Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>
>             Discussion: https://postgr.es/m/CAD21AoA4WHthN5uU6+WScZ7+J_RcEjmcuH94qcoUPuB42ShXzg@mail.gmail.com
> -->         Backpatch: 13-, where autovacuum_vacuum_insert_threshold was added.
>
> This was backpatched into PG 13.3, which was released last week:
>
>             <listitem>
>         <!--
>         Author: Peter Geoghegan <pg@bowt.ie>
>         Branch: master [9f3665fbf] 2021-03-10 16:27:01 -0800
>         Branch: REL_13_STABLE [9663d1244] 2021-03-10 16:26:58 -0800
>         Author: Peter Geoghegan <pg@bowt.ie>
>         Branch: master [5f8727f5a] 2021-03-10 17:07:57 -0800
>         Branch: REL_13_STABLE [1fc5a5738] 2021-03-10 17:07:55 -0800
>         -->
>              <para>
>               Disable the <varname>vacuum_cleanup_index_scale_factor</varname>
>               parameter and storage option (Peter Geoghegan)
>              </para>
>
>              <para>
>               The notion of tracking <quote>stale</quote> index statistics proved
>               to interact badly with
>               the <varname>autovacuum_vacuum_insert_threshold</varname> parameter,
>               resulting in unnecessary full-index scans and consequent degradation
>               of autovacuum performance.  The latter mechanism seems superior, so
>               remove the stale-statistics logic.  The control parameter for that,
>               <varname>vacuum_cleanup_index_scale_factor</varname>, will be
>               removed entirely in v14.  In v13, it remains present to avoid
>               breaking existing configuration files, but it no longer does
>               anything.
>              </para>
>             </listitem>
>
> Therefore, it didn't show up in my src/tools/git_changelog output, and I
> did not include it.
>

Thanks for your explanation. I understood and agreed not to include it
in PG14 release note.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/