Re: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1
От | Guillaume Lelarge |
---|---|
Тема | Re: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1 |
Дата | |
Msg-id | CAECtzeVyt3Z4tpjfZJ5kXf-5E8c=8acdnhM=Sn5bsR19FQQhKg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1 ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>) |
Ответы |
RE: "actual time" in QUERY PLAN for parallel operation when loops is bigger than 1
|
Список | pgsql-docs |
Hi,
Wednesday, November 17, 2021 6:29 AM, nikolai.berkoff <nikolai.berkoff@pm.me> wrote:
>
> Parallel query is explained in
> https://www.postgresql.org/docs/14/how-parallel-query-works.html and
> https://www.postgresql.org/docs/14/parallel-plans.html
>
> The docs seem clear to me that as the nodes are executed in parallel then the
> time execution time is not 140.036*3. The 140.036 value is actual time the Parallel
> Seq Scan nodes ran for but there were up to 2 running in parallel.
Thanks for your reply.
I read your references but still confused about the 'loops' in parallel query result.
> -> Parallel Seq Scan on c (cost=0.00..8591.67 rows=416667 width=0) (actual time=0.030..140.036 rows=333333 loops=3)
In my previous example, actual row number is 333333*3=1e6(which is correct), so I think the actual time is 140.036*3ms.
Do your think the loops(3) has no meaning for parallel scan node when calculate actual time?
As far as I understand it, you have to multiply the number of rows by the number of loops, but this doesn't apply to duration at least for parallel queries.
Guillaume.
В списке pgsql-docs по дате отправления: