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)
