El lun, 25 jul 2022 a la(s) 14:19, Anthony Sotolongo (asotolongo@gmail.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.