Re: Parallel workers stats in pg_stat_database - Mailing list pgsql-hackers

From Michael Banck
Subject Re: Parallel workers stats in pg_stat_database
Date
Msg-id 6733734b.050a0220.ff1bf.057d@mx.google.com
Whole thread Raw
In response to Re: Parallel workers stats in pg_stat_database  (Benoit Lobréau <benoit.lobreau@dalibo.com>)
Responses Re: Parallel workers stats in pg_stat_database
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE
Next
From: Andres Freund
Date:
Subject: Re: Commit Timestamp and LSN Inversion issue