Re: Parallel workers stats in pg_stat_database

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Benoit Lobréau <benoit.lobreau@dalibo.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-01T07:27:36Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add two attributes to pg_stat_database for parallel workers activity

  2. Introduce two fields in EState to track parallel worker activity