Re: Asymmetric partition-wise JOIN - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Asymmetric partition-wise JOIN
Date
Msg-id CAExHW5tr0mdEzjGth4mFNPcOBxrU=VfH5zhakg9RKeW5HZq5ng@mail.gmail.com
Whole thread Raw
In response to Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <lepihov@gmail.com>)
List pgsql-hackers
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>
> > But the clauses of A parameterized by P will produce different
> > translations for each of the partitions. I think we will need
> > different RelOptInfos (for A) to store these translations.
>
> Does the answer above resolved this issue?

May be. There are other problematic areas like EvalPlanQual, Rescans,
reparameterised paths which can blow up if we use the same RelOptInfo
for different scans of the same relation. It will be good to test
those. And also A need not be a simple relation; it could be join as
well.

>
> > The relid is also used to track the scans at executor level. Since we
> > have so many scans on A, each may be using different plan, we will
> > need different ids for those.
>
> I don't understand this sentence. Which way executor uses this index of
> RelOptInfo ?

See Scan::scanrelid

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Oversight in reparameterize_path_by_child leading to executor crash
Next
From: Ashutosh Bapat
Date:
Subject: Re: RFC: Logging plan of the running query