From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Parallelize correlated subqueries that execute within each worker |
Date: | 2025-07-03 14:04:22 |
Message-ID: | 87frfd9xqx.fsf@163.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi James:
Very nice to find this topic, I am recently working on this topic [1] as
well without finding this topic has been discussed before. I just go
through this thread and find it goes with a different direction with mine.
would you mind to check my soluation to see is there any case I can't
cover? I suggested this because my soluation should be much easier than
yours. But I'm not suprised to know I'm miss some obvious keypoint.
>
>> One of the queries in in incremental_sort changed plans a little bit:
>>
>> explain (costs off) select distinct
>> unique1,
>> (select t.unique1 from tenk1 where tenk1.unique1 = t.unique1)
>> from tenk1 t, generate_series(1, 1000);
>>
>> switched from
>>
>> Unique (cost=18582710.41..18747375.21 rows=10000 width=8)
>> -> Gather Merge (cost=18582710.41..18697375.21 rows=10000000 ...)
>> Workers Planned: 2
>> -> Sort (cost=18582710.39..18593127.06 rows=4166667 ...)
>> Sort Key: t.unique1, ((SubPlan 1))
>> ...
>>
>> to
>>
>> Unique (cost=18582710.41..18614268.91 rows=10000 ...)
>> -> Gather Merge (cost=18582710.41..18614168.91 rows=20000 ...)
>> Workers Planned: 2
>> -> Unique (cost=18582710.39..18613960.39 rows=10000 ...)
>> -> Sort (cost=18582710.39..18593127.06 ...)
>> Sort Key: t.unique1, ((SubPlan 1))
>> ...
>>
>> which probably makes sense, as the cost estimate decreases a bit.
>
> Off the cuff that seems fine. I'll read it over again when I send the
> updated series.
I had a detailed explaination for this plan change in [1] and I think
this could be amazing gain no matter which way we go finally.
[1] https://www.postgresql.org/message-id/871pqzm5wj.fsf@163.com
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-07-03 14:06:58 | Re: Explicitly enable meson features in CI |
Previous Message | Nazir Bilal Yavuz | 2025-07-03 13:50:27 | Re: Explicitly enable meson features in CI |