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

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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.