Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes
Date: 2024-11-11 02:04:57
Message-ID: ZzFmSd1Ry5x4zOeu@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 08, 2024 at 06:24:54PM +0300, Alena Rybakina wrote:
> yes, I agree with you. Even when I experimented with vacuum settings for
> database and used my vacuum statistics patch [0] for analyzes , I first
> looked at this change in the number of blocks or deleted rows at the
> database level,
> and only then did an analysis of each table and index.
>
> [0] https://commitfest.postgresql.org/50/5012/

As hinted on other related threads like around [1], I am so-so about
the proposal of these numbers at table and index level now that we
have e7a9496de906 and 5d4298e75f25.

In such cases, I apply the concept that I call the "Mention Bien" (or
when you get a baccalaureat diploma with honors and with a 14~16/20 in
France). What we have is not perfect, still it's good enough to get
a 14/20 IMO, making hopefully 70~80% of users happy with these new
metrics. Perhaps I'm wrong, but I'd be curious to know if this
thread's proposal is required at all at the end.

I have not looked at the logging proposal yet.

[1]: https://www.postgresql.org/message-id/Zywxw7vqPLBfVfXN@paquier.xyz
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiro Ikeda 2024-11-11 02:53:07 Re: Avoiding superfluous buffer locking during nbtree backwards scans
Previous Message Michael Paquier 2024-11-11 01:51:54 Re: Parallel workers stats in pg_stat_database