Re: Add last_vacuum_index_scans in pg_stat_all_tables

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Ken Kato <katouknl(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add last_vacuum_index_scans in pg_stat_all_tables
Date: 2022-07-08 16:40:52
Message-ID: 20220708164052.bp62uhma56v7u7n5@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Jul-04, Ken Kato wrote:

> I think having number of index scans of the last vacuum in
> pg_stat_all_tables can be helpful. This value shows how efficiently vacuums
> have performed and can be an indicator to increase maintenance_work_mem.

Yeah, this would be a good metric to expose, since it directly tells how
to set autovacuum_work_mem. I'm not sure that the shape you propose is
correct, though, because each vacuum run would clobber whatever value
was there before. No other stats counter works that way; they are all
additive. But I'm not sure that adding the current number each time is
sensible, either, because then the only thing you know is the average of
the last X runs, which doesn't tell you much.

Saving some sort of history would be much more useful, but of course a
lot more work.

> It was proposed previously[1], but it was not accepted due to the limitation
> of stats collector. Statistics are now stored in shared memory, so we got
> more rooms to store statistics. I think this statistics is still valuable
> for some people, so I am proposing this again.

> [1] https://www.postgresql.org/message-id/20171010.192616.108347483.horiguchi.kyotaro%40lab.ntt.co.jp

I read this thread, but what was proposed there is a bunch of metrics
that are not this one. The discussions there centered about how it
would be unacceptable to incur in the space cost that would be taken by
adding autovacuum-related metrics completely different from the one you
propose. That debate is now over, so we're clear to proceed. But we
need to agree on what to add.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-07-08 16:45:34 Re: automatically generating node support functions
Previous Message Zhihong Yu 2022-07-08 16:40:25 Aggregate leads to superfluous projection from the scan