From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Anthony Sotolongo <asotolongo(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org, daymelbonne(at)gmail(dot)com |
Subject: | Re: Expose Parallelism counters planned/execute in pg_stat_statements |
Date: | 2022-07-23 04:03:34 |
Message-ID: | 20220723040334.q4w6zjjphozf25og@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-23 04:05:31 | Re: Removing obsolete configure checks |
Previous Message | Tom Lane | 2022-07-23 03:54:27 | Re: Make name optional in CREATE STATISTICS |