Re: Expose Parallelism counters planned/execute in pg_stat_statements

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Expose Parallelism counters planned/execute in pg_stat_statements
Дата
Msg-id 20220723040334.q4w6zjjphozf25og@jrouhaud
обсуждение исходный текст
Ответ на Re: Expose Parallelism counters planned/execute in pg_stat_statements  (Anthony Sotolongo <asotolongo@gmail.com>)
Ответы Re: Expose Parallelism counters planned/execute in pg_stat_statements  (Anthony Sotolongo <asotolongo@gmail.com>)
Список pgsql-hackers
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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Make name optional in CREATE STATISTICS
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Removing obsolete configure checks