Re: Expose Parallelism counters planned/execute in pg_stat_statements

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