Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Tender Wang <tndrwang@gmail.com>
From: tender wang <tndrwang@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-09-07T09:56:40Z
Lists: pgsql-hackers
Attachments
- v2-0001-Parallel-seq-scan-should-consider-materila-inner-.patch (text/plain) patch v2-0001
Richard Guo <guofenglinux@gmail.com> 于2023年9月5日周二 18:51写道:
>
> On Tue, Sep 5, 2023 at 4:52 PM tender wang <tndrwang@gmail.com> wrote:
>
>> I recently run benchmark[1] on master, but I found performance problem
>> as below:
>> ...
>>
>> I debug the code and find consider_parallel_nestloop() doesn't consider
>> materialized form of the cheapest inner path.
>>
>
> Yeah, this seems an omission in commit 45be99f8. I reviewed the patch
> and here are some comments.
>
> * I think we should not consider materializing the cheapest inner path
> if we're doing JOIN_UNIQUE_INNER, because in this case we have to
> unique-ify the inner path.
>
That's right. The V2 patch has been fixed.
> * I think we can check if it'd be parallel safe before creating the
> material path, thus avoid the creation in unsafe cases.
>
Agreed.
> * I don't think the test case you added works for the code changes.
> Maybe a plan likes below is better:
>
Agreed.
explain (costs off)
> select * from tenk1, tenk2 where tenk1.two = tenk2.two;
> QUERY PLAN
> ----------------------------------------------
> Gather
> Workers Planned: 4
> -> Nested Loop
> Join Filter: (tenk1.two = tenk2.two)
> -> Parallel Seq Scan on tenk1
> -> Materialize
> -> Seq Scan on tenk2
> (7 rows)
>
> Thanks
> Richard
>
Commits
-
Fix unstable test in select_parallel.sql
- 7e187a7386cc 18.0 landed
-
Consider materializing the cheapest inner path in parallel nestloop
- 22d946b0f86f 18.0 landed
-
doc PG 17 relnotes: adjust IN wording
- 8fea1bd5411b 17.0 cited
-
Support parallel joins, and make related improvements.
- 45be99f8cd5d 9.6.0 cited