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

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

  1. Fix unstable test in select_parallel.sql

  2. Consider materializing the cheapest inner path in parallel nestloop

  3. doc PG 17 relnotes: adjust IN wording

  4. Support parallel joins, and make related improvements.