Re: Parallel workers stats in pg_stat_database
От | Michael Banck |
---|---|
Тема | Re: Parallel workers stats in pg_stat_database |
Дата | |
Msg-id | 6733734b.050a0220.ff1bf.057d@mx.google.com обсуждение исходный текст |
Ответ на | Re: Parallel workers stats in pg_stat_database (Benoit Lobréau <benoit.lobreau@dalibo.com>) |
Ответы |
Re: Parallel workers stats in pg_stat_database
|
Список | 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 по дате отправления: