Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() - Mailing list pgsql-hackers

From tender wang
Subject Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date
Msg-id CAHewXN=4=ntM2OsJBHgJzmXxnd_0xtsCwnUhEVxgHSkBsBMO1Q@mail.gmail.com
Whole thread Raw
In response to Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers


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
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: information_schema and not-null constraints
Next
From: Amit Kapila
Date:
Subject: Re: Impact of checkpointer during pg_upgrade