Hi, On Wed, Oct 14, 2026 at 4:51 AM Alena Rybakina <[email protected]> wrote: > > Rebased version and fixed some bugs that have been found: > > Sorry, I used outdated master version from my fork, now it should be correct.
Thanks for updating the patches, and sorry for the delay. I looked at the v47 patches and here are some thoughts. 1/ 0001: I still think reporting how many index tuples the vacuum has deleted is worth having on its own. All the core indexes provide that stat via tuples_removed, but the VACUUM VERBOSE and the autovacuum log output is missing it. I suggest we discuss this separately if you prefer. PS: It may be worth reporting num_index_tuples too, but that ends up as pg_class.reltuples, so maybe not. 2/ 0002-0004: I'm having a hard time understanding how these accumulated stats in pg_stats_all* views help analyze past vacuum runs. I understand that 30a6ed0 tried to answer the avg time spent on each past run, but that doesn't necessarily mean we should add most of the vacuum stats, which we already report via the log output. That seems unnecessary to me, especially when you are also proposing a hook to emit such stats out of the core. My worry is that we might end up adding all the log output to views eventually. 3/ 0002: I might instead be okay with enhancing the log output with the things missing today, for example, per-index elapsed time and per-index delay. 4/ 0003: Failsafe count is already emitted in the log output, so emitting it elsewhere seems unnecessary. 5/ 0004: VACUUM command fails when it encounters an error, which is reported to the user, so there's no point in counting that separately. Autovacuum emits the error with proper context and continues with the rest. I'm also not sure how useful it is to emit this via views, and doing so seems unnecessary too. 6/ 0005: I don't think we have agreement from other hackers to expose the vacuum stats via a hook. Even then, I don't think core should have a full-blown extension around that hook. We can simplify things by emitting the vacuum stats via a hook, plus a sample src/test/module covering the code and showing the usage pattern. In that test module, I would just collect the stats and store them in a simple shmem, or even just elog them to keep it simpler. 7/ 0006-0008: As mentioned, I prefer not to have a core vacuum extension. Also, don't we already have WAL usage and shared buffers usage metrics in the existing log output? 8/ 0009: Emitting all-visible/all-frozen clear stats is a separate thing to discuss. Backends clear them, and I don't think they are related here. In short, I strongly feel we can simplify this feature to move forward. Reporting the number of index tuples removed in the log output and all-visible/all-frozen stats could be discussed in separate threads. One patch to define a structure with all the fields that the existing log output emits via elog, and expose it via a new hook with a simple test module. Thoughts? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
