Re: Autovacuum on partitioned table (autoanalyze)

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)