Re: autovac issue with large number of tables

Hi,

On Wed, Aug 12, 2020 at 2:46 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So I think Kasahara-san's point is that the shared memory stats collector
> might wipe out those costs, depending on how it's implemented. (I've not
> looked at that patch in a long time either, so I don't know how much it'd
> cut the reader-side costs. But maybe it'd be substantial.)
Thanks for your clarification, that's what I wanted to say.
Sorry for the lack of explanation.

> I think the real issue here is autovac_refresh_stats's insistence that it
> shouldn't throttle pgstats re-reads in workers.
I agree that.

> I wonder if we could have table_recheck_autovac do two probes of the stats
> data. First probe the existing stats data, and if it shows the table to
> be already vacuumed, return immediately. If not, *then* force a stats
> re-read, and check a second time.
Does the above mean that the second and subsequent table_recheck_autovac()
will be improved to first check using the previous refreshed statistics?
I think that certainly works.

If that's correct, I'll try to create a patch for the PoC.

Best regards,

--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com