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

From Richard Guo
Subject Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date
Msg-id CAMbWs48TaubitHF+JXqysbSHLCzTLOU9PD3zpLGFUtizsonAMA@mail.gmail.com
Whole thread Raw
In response to Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Tender Wang <tndrwang@gmail.com>)
Responses Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
List pgsql-hackers
On Tue, Jun 4, 2024 at 6:51 PM Tender Wang <tndrwang@gmail.com> wrote:
> Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
>
> * 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.
>
> We don't consider material inner path if jointype is JOIN_UNIQUE_INNER in match_unsorted_order().
> So here is as same logic as match_unsorted_order(). I added comments to explain why.

I looked through the v4 patch and found an issue.  For the plan diff:

+         ->  Nested Loop
+               ->  Parallel Seq Scan on prt1_p1 t1_1
+               ->  Materialize
+                     ->  Sample Scan on prt1_p1 t2_1
+                           Sampling: system (t1_1.a) REPEATABLE (t1_1.b)
+                           Filter: (t1_1.a = a)

This does not seem correct to me.  The inner path is parameterized by
the outer rel, in which case it does not make sense to add a Materialize
node on top of it.

I updated the patch to include a check in consider_parallel_nestloop
ensuring that inner_cheapest_total is not parameterized by outerrel
before materializing it.  I also tweaked the comments, test cases and
commit message.

Thanks
Richard

Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: [PATCH] Improve error message when trying to lock virtual tuple.
Next
From: Ashutosh Bapat
Date:
Subject: Re: Is creating logical replication slots in template databases useful at all?