From: | Anthony Sotolongo <asotolongo(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(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-25 19:19:22 |
Message-ID: | 4c5577d2-6249-5d29-aec0-ed3d2dd9b2e7@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-25 19:46:18 | Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS |
Previous Message | Nathan Bossart | 2022-07-25 19:04:19 | Re: optimize lookups in snapshot [sub]xip arrays |