Re: Vacuum statistics

Hi,

On Wed, Oct 14, 2026 at 4:51 AM Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru> 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