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
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 |