From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: yuzuko <yuzukohosoya@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: David Steele <david@pgmasters.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Daniel Gustafsson <daniel@yesql.se>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Greg Stark <stark@mit.edu>
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Date: Tue, 10 Aug 2021 19:00:09 -0400
Message-ID: <202108102300.wf5nirpzia52@alvherre.pgsql> (raw)
In-Reply-To: <202108100010.vo4pr5ltu4qo@alvherre.pgsql>
On 2021-Aug-09, Alvaro Herrera wrote:
> > 3) What is the goal of the autovac_refresh_stats() after the loop doing
> > pgstat_report_anl_ancestors()? I think it'll be common that the stats
> > collector hasn't even processed the incoming messages by that point, not to
> > speak of actually having written out a new stats file. If it took less than
> > 10ms (PGSTAT_RETRY_DELAY) to get to autovac_refresh_stats(),
> > backend_read_statsfile() will not wait for a new stats file to be written
> > out, and we'll just re-read the state we previously did.
> >
> > It's pretty expensive to re-read the stats file in some workloads, so I'm a
> > bit concerned that we end up significantly increasing the amount of stats
> > updates/reads, without actually gaining anything reliable?
>
> This is done once per autovacuum run and the point is precisely to let
> the next block absorb the updates that were sent. In manual ANALYZE we
> do it to inform future autovacuum runs.
>
> Note that the PGSTAT_RETRY_DELAY limit is used by the autovac launcher
> only, and this code is running in the worker; we do flush out the old
> data. Yes, it's expensive, but we're not doing it once per table, just
> once per worker run.
I misunderstood what you were talking about here -- I thought it was
about the delay in autovac_refresh_stats (STATS_READ_DELAY, 1s). Now
that I look at this again I realize what your point is, and you're
right, there isn't sufficient time for the collector to absorb the
messages we sent before the next scan pg_class scan starts.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, andres@anarazel.de, horiguchi.kyotaro@lab.ntt.co.jp, yuzukohosoya@gmail.com, tomas.vondra@enterprisedb.com, david@pgmasters.net, horikyota.ntt@gmail.com, pryzby@telsasoft.com, daniel@yesql.se, amitlangote09@gmail.com, masahiko.sawada@2ndquadrant.com, laurenz.albe@cybertec.at, pgsql-hackers@lists.postgresql.org, stark@mit.edu
Subject: Re: Autovacuum on partitioned table (autoanalyze)
In-Reply-To: <202108102300.wf5nirpzia52@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox