Re: Parallel workers stats in pg_stat_database
Michael Banck <mbanck@gmx.net>
From: Michael Banck <mbanck@gmx.net>
To: Benoit Lobréau <benoit.lobreau@dalibo.com>
Cc: Guillaume Lelarge <guillaume@lelarge.info>, Michael Paquier <michael@paquier.xyz>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-12T15:24:57Z
Lists: pgsql-hackers
Hi, On Tue, Nov 12, 2024 at 03:56:11PM +0100, Benoit Lobréau wrote: > On 11/12/24 15:05, Michael Banck wrote: > > I was wondering about the weird new column name workers_to_launch when I > > read the commit message - AFAICT this has been an internal term so far, > > and this is the first time we expose it to users? > > > > I personally find (parallel_)workers_planned/launched clearer from a > > user perspective, was it discussed that we need to follow the internal > > terms here? If so, I missed that discussion in this thread (and the > > other thread that lead to cf54a2c00). > > I initiallly called it like that but changed it to mirror the column > name added in pg_stat_statements for coherence sake. Ah, I mixed up the threads about adding parallel stats to pg_stat_all_tables and pg_stat_statements - I only reviewed the former, but in the latter, Michael writes: |- I've been struggling a bit on the "planned" vs "launched" terms used |in the names for the counters. It is inconsistent with the backend |state, where we talk about workers "to launch" and workers "launched". |"planned" does not really apply to utilities, as this may not be |planned per se. I am not sure "backend state" is a good reason (unless it is exposed somewhere to users?), but the point about utilities does make sense I guess. Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add two attributes to pg_stat_database for parallel workers activity
- e7a9496de906 18.0 landed
-
Introduce two fields in EState to track parallel worker activity
- de3a2ea3b264 18.0 landed