Re: Expose Parallelism counters planned/execute in pg_stat_statements

Hi,

El lun, 25 jul 2022 a la(s) 14:19, Anthony Sotolongo (asotolongo(at)gmail(dot)com)
escribió:

> On 23-07-22 00:03, Julien Rouhaud wrote:
> > 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.
>
> Thanks for your time and feedback, yes we were missing some details, so
> we need to rethink some points to continue
>

We have rewritten the patch and added the necessary columns to have the
number of times a parallel query plan was not executed using parallelism.

We are investigating how to add more information related to the workers
created
by the Gather/GatherMerge nodes, but it is not a trivial task.

Regards.