Re: Parallel workers stats in pg_stat_database

2024-11-12 Thread Benoit Lobréau
On 11/12/24 16:24, Michael Banck wrote: 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. We only track parallel workers used by queries right now. Parallel index builds (btree & brin) and vacuum

Re: Parallel workers stats in pg_stat_database

2024-11-12 Thread Michael Banck
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 e

Re: Parallel workers stats in pg_stat_database

2024-11-12 Thread Benoit Lobréau
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

Re: Parallel workers stats in pg_stat_database

2024-11-12 Thread Michael Banck
Hi, On Fri, Oct 11, 2024 at 09:33:48AM +0200, Guillaume Lelarge wrote: > FWIW, with the recent commits of the pg_stat_statements patch, you need a > slight change in the patch I sent on this thread. You'll find a patch > attached to do that. You need to apply it after a rebase to master. > > -

Re: Parallel workers stats in pg_stat_database

2024-11-11 Thread Benoit Lobréau
On 11/11/24 02:51, Michael Paquier wrote: Okidoki, applied. If tweaks are necessary depending on the feedback, like column names, let's tackle things as required. We still have a good chunk of time for this release cycle. -- Michael Thanks ! -- Benoit Lobréau Consultant http://dalibo.com

Re: Parallel workers stats in pg_stat_database

2024-11-10 Thread Michael Paquier
On Fri, Nov 08, 2024 at 03:13:35PM +0100, Benoit Lobréau wrote: > I just reread the patch. > Thanks for the changes. It looks great. Okidoki, applied. If tweaks are necessary depending on the feedback, like column names, let's tackle things as required. We still have a good chunk of time for thi

Re: Parallel workers stats in pg_stat_database

2024-11-08 Thread Benoit Lobréau
On 11/8/24 05:08, Michael Paquier wrote: On Thu, Nov 07, 2024 at 02:36:58PM +0900, Michael Paquier wrote: Incorrect comment format, about which pgindent does not complain.. .. But pgindent complains in execMain.c and pgstat_database.c. These are only nits, the patch is fine. If anybody has o

Re: Parallel workers stats in pg_stat_database

2024-11-07 Thread Michael Paquier
On Thu, Nov 07, 2024 at 02:36:58PM +0900, Michael Paquier wrote: > Incorrect comment format, about which pgindent does not complain.. > > .. But pgindent complains in execMain.c and pgstat_database.c. These > are only nits, the patch is fine. If anybody has objections or > comments, feel free.

Re: Parallel workers stats in pg_stat_database

2024-11-06 Thread Michael Paquier
On Sat, Oct 12, 2024 at 01:14:54AM +0200, Benoit Lobréau wrote: > Here is an updated version, I modified it to: > > * have the same wording in the doc and code (planned => to_launch) > * split de declaration from the rest (and have the same code as the parallel > worker logging patch) Thanks for

Re: Parallel workers stats in pg_stat_database

2024-10-11 Thread Benoit Lobréau
On 10/11/24 09:33, Guillaume Lelarge wrote: FWIW, with the recent commits of the pg_stat_statements patch, you need a slight change in the patch I sent on this thread. You'll find a patch attached to do that. You need to apply it after a rebase to master. Thanks. Here is an updated version, I

Re: Parallel workers stats in pg_stat_database

2024-10-11 Thread Guillaume Lelarge
Le mar. 8 oct. 2024 à 14:03, Benoit Lobréau a écrit : > On 10/7/24 10:19, Guillaume Lelarge wrote: > > I've done the split, but I didn't go any further than that. > > Thank you Guillaume. I have done the rest of the reformatting > suggested by Michael but I decided to see If I have similar stuff

Re: Parallel workers stats in pg_stat_database

2024-10-08 Thread Benoit Lobréau
On 10/7/24 10:19, Guillaume Lelarge wrote: I've done the split, but I didn't go any further than that. Thank you Guillaume. I have done the rest of the reformatting suggested by Michael but I decided to see If I have similar stuff in my logging patch and refactor accordingly if needed before po

Re: Parallel workers stats in pg_stat_database

2024-10-07 Thread Guillaume Lelarge
Hey, Le mer. 2 oct. 2024 à 11:12, Benoit Lobréau a écrit : > Hi, > > Thanks for your imput ! I will fix the doc as proposed and do the split > as soon as I have time. > > I've done the split, but I didn't go any further than that. Two patches attached: * v5-0001 adds the metrics (same patch tha

Re: Parallel workers stats in pg_stat_database

2024-10-02 Thread Michael Paquier
On Wed, Oct 02, 2024 at 11:12:37AM +0200, Benoit Lobréau wrote: > My collegues and I had a discussion about what could be done to improve > parallelism observability in PostgreSQL [0]. We thought about several > places to do it for several use cases. > > Guillaume Lelarge worked on pg_stat_stateme

Re: Parallel workers stats in pg_stat_database

2024-10-02 Thread Benoit Lobréau
Hi, Thanks for your imput ! I will fix the doc as proposed and do the split as soon as I have time. On 10/1/24 09:27, Michael Paquier wrote: I'm less a fan of the addition for utilities because these are less common operations. My thought process was that in order to size max_parallel_worke

Re: Parallel workers stats in pg_stat_database

2024-10-01 Thread Michael Paquier
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?

Re: Parallel workers stats in pg_stat_database

2024-09-17 Thread Benoit Lobréau
Here is an updated patch fixing the aforementionned problems with tests and vacuum stats. -- Benoit Lobréau Consultant http://dalibo.comFrom 1b52f5fb4e977599b8925c69193d31148042ca7d Mon Sep 17 00:00:00 2001 From: benoit Date: Wed, 28 Aug 2024 02:27:13 +0200 Subject: [PATCH] Adds four parallel wo

Re: Parallel workers stats in pg_stat_database

2024-09-04 Thread Benoit Lobréau
On 9/4/24 08:46, Bertrand Drouvot wrote:> What about moving the tests to places where it's "guaranteed" to get parallel workers involved? For example, a "parallel_maint_workers" only test could be done in vacuum_parallel.sql. Thank you ! I was too focussed on the stat part and missed the obviou

Re: Parallel workers stats in pg_stat_database

2024-09-03 Thread Bertrand Drouvot
Hi, On Tue, Sep 03, 2024 at 02:34:06PM +0200, Benoit Lobréau wrote: > I noticed that the tests are still not stable. I tried using tenk2 > but fail to have stable plans. I'd love to have pointers on that front. What about moving the tests to places where it's "guaranteed" to get parallel workers

Re: Parallel workers stats in pg_stat_database

2024-09-03 Thread Benoit Lobréau
Hi, This new version avoids updating the stats for non parallel queries. I noticed that the tests are still not stable. I tried using tenk2 but fail to have stable plans. I'd love to have pointers on that front. -- Benoit Lobréau Consultant http://dalibo.comFrom 5e4401c865f77ed447b8b3f25aac0ffa

Re: Parallel workers stats in pg_stat_database

2024-08-29 Thread Benoit Lobréau
Hi, This is a new patch which: * fixes some typos * changes the execgather / execgathermerge code so that the stats are accumulated in EState and inserted in pg_stat_database only once, during ExecutorEnd * adds tests (very ugly, but I could get the parallel plan to be stable across make chec