Re: Expose Parallelism counters planned/execute in pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Expose Parallelism counters planned/execute in pg_stat_statements
Date
Msg-id 20220723040334.q4w6zjjphozf25og@jrouhaud
Whole thread Raw
In response to Re: Expose Parallelism counters planned/execute in pg_stat_statements  (Anthony Sotolongo <asotolongo@gmail.com>)
Responses Re: Expose Parallelism counters planned/execute in pg_stat_statements
List pgsql-hackers
Hi,

On Fri, Jul 22, 2022 at 02:11:35PM -0400, Anthony Sotolongo wrote:
>
> On 22-07-22 12:08, Julien Rouhaud wrote:
> >
> > With your current patch it only says if the plan and execution had parallelism
> > enabled, but not if it could actually use with parallelism at all.  It gives
> > some information, but it's not that useful on its own.
>
> The original idea of this patch was  identify when occurred some of the
> circumstances under which it was  impossible to execute that plan in
> parallel at execution time
>
> as mentioned on the documentation at [1]
>
> For example:
>
> Due to the different client configuration, the execution behavior can be 
> different , and can affect the performance:
>
> As you can see in the above execution plan
>
>
> From psql
>
>             ->  Gather Merge  (cost=779747.43..795700.62 rows=126492
> width=40) (actual time=1109.515..1472.369 rows=267351 loops=1)
>                   Output: t.entity_node_id, t.configuration_id,
> t.stream_def_id, t.run_type_id, t.state_datetime, (PARTIAL count(1))
>                   Workers Planned: 6
>                   Workers Launched: 6
>                   ->  Partial GroupAggregate (cost=778747.33..779327.09
> rows=21082 width=40) (actual time=889.129..974.028 rows=38193 loops=7)
>
> From jdbc (from dbeaver)
>
>             ->  Gather Merge  (cost=779747.43..795700.62 rows=126492
> width=40) (actual time=4383.576..4385.856 rows=398 loops=1)
>                   Output: t.entity_node_id, t.configuration_id,
> t.stream_def_id, t.run_type_id, t.state_datetime, (PARTIAL count(1))
>                   Workers Planned: 6
>                   Workers Launched: 0
>                   ->  Partial GroupAggregate (cost=778747.33..779327.09
> rows=21082 width=40) (actual time=4383.574..4385.814 rows=398 loops=1)
>
> This example was  discussed also at this Thread [2]
>
> With these PSS counters will be easily identified when some of these causes
> are happening.

I agree it can be hard to identify, but I don't think that your proposed
approach is enough to be able to do so.  There's no guarantee of an exact 1:1
mapping between planning and execution, so you could totally see the same value
for parallel_planned and parallel_exec and still have the dbeaver behavior
happening.

If you want to be able to distinguish "plan was parallel but execution was
forced to disable it" from "plan wasn't parallel, so was the execution", you
need some specific counters for both situations.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Make name optional in CREATE STATISTICS
Next
From: Tom Lane
Date:
Subject: Re: Removing obsolete configure checks