Re: PG 14 release notes, first draft

On Tue, May 18, 2021 at 11:07 PM Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)bowt(dot)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(at)bowt(dot)ie>
> Reviewed-By: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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(at)bowt(dot)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(at)bowt(dot)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/