Hi, On Wed, Aug 12, 2020 at 2:46 AM Tom Lane <t...@sss.pgh.pa.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
