Re: Parallel workers stats in pg_stat_database

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel workers stats in pg_stat_database
Date: 2024-11-07 05:36:58
Message-ID: ZyxR-krMxYp5uop7@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 12, 2024 at 01:14:54AM +0200, Benoit Lobréau wrote:
> Here is an updated version, I modified it to:
>
> * have the same wording in the doc and code (planned => to_launch)
> * split de declaration from the rest (and have the same code as the parallel
> worker logging patch)

Thanks for the updated patch set.

I've been thinking about this proposal for the two counters with
pg_stat_database in 0001, and I am going to side with the argument
that it sucks to not have this information except if
pg_stat_statements is enabled on an instance. It would be a different
discussion if PGSS were to be in core, and if that were to happen we
could perhaps remove these counters from pg_stat_database, but there
is no way to be sure if this is going to happen, as well. And this
information is useful for the GUC settings.

+/*
+ * reports parallel_workers_to_launch and parallel_workers_launched into
+ * PgStat_StatDBEntry
+ */
Perhaps a reword with:
"Notify the stats system about parallel worker information."

+/* pg_stat_get_db_parallel_workers_to_launch*/
[...]
+/* pg_stat_get_db_parallel_workers_launched*/

Incorrect comment format, about which pgindent does not complain..

.. But pgindent complains in execMain.c and pgstat_database.c. These
are only nits, the patch is fine. If anybody has objections or
comments, feel free.

Now, I am not really on board with 0002 and 0003 about the tracking of
the maintenance workers, which reflect operations that happen less
often than what 0001 is covering. Perhaps this would have more
value if autovacuum supported parallel operations, though.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kasaharatt 2024-11-07 05:37:50 Doc: typo in ddl.sgml
Previous Message Amit Kapila 2024-11-07 05:34:35 Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY