From: | Daymel Bonne Solís <daymelbonne(at)gmail(dot)com> |
---|---|
To: | Anthony Sotolongo <asotolongo(at)gmail(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Expose Parallelism counters planned/execute in pg_stat_statements |
Date: | 2022-07-29 13:36:44 |
Message-ID: | CADGXAPg7eNfYA1Rjxi-uzRxaKU3HkTXYa2dBJMuJF_KhTHAV2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Add-parallel-counters-to-pg_stat_statements.patch | text/x-patch | 20.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2022-07-29 14:32:08 | Re: making relfilenodes 56 bits |
Previous Message | Justin Pryzby | 2022-07-29 13:29:15 | Re: doc phrase: "inheritance child" |