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: 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-10-01 07:27:36
Message-ID: ZvukaLyC7lTxpLah@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 17, 2024 at 02:22:59PM +0200, Benoit Lobréau wrote:
> Here is an updated patch fixing the aforementionned problems
> with tests and vacuum stats.

Your patch needs a rebase.

+ Number of parallel workers obtained by utilities on this database

s/obtained/launched/ for consistency?

I like the general idea of the patch because it is rather difficult
now to know how to tune these parameters. If I were to put a priority
on both ideas, the possibility of being able to look at the number of
workers launched vs requested in the executor is higher, and I'm less
a fan of the addition for utilities because these are less common
operations. So I'd suggest to split the patch into two pieces, one
for each, if we do that at database level, but..

Actually, could we do better than what's proposed here? How about
presenting an aggregate of this data in pg_stat_statements for each
query instead? The ExecutorEnd() hook has an access to the executor
state, so the number of workers planned and launched could be given by
the execution nodes to the estate, then fed back to
pg_stat_statements. You are already doing most of the work with the
introduction of es_workers_launched and es_workers_planned.

If you want to get the data across a database, then just sum up the
counters for all the queries, applying a filter with the number of
calls, for example.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2024-10-01 07:28:54 Re: pg_upgrade check for invalid databases
Previous Message Anthonin Bonnefoy 2024-10-01 07:26:40 Re: Set query_id for query contained in utility statement