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

From Andrei Lepikhov
Subject Re: Asymmetric partition-wise JOIN
Date
Msg-id 9dede0b2-f331-4360-ab51-06780957b356@gmail.com
Whole thread Raw
In response to Re: Asymmetric partition-wise JOIN  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Asymmetric partition-wise JOIN
List pgsql-hackers
On 18/10/2023 16:59, Ashutosh Bapat wrote:
> On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
>>> 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
> 
Hi,

In the attachment, you will find a fresh version of the patch.
I've analysed the danger of the same RelOptInfo index for the executor. 
In the examples I found (scared), it is still not a problem because 
ExecQual() does all the jobs at one operation and doesn't intersect with 
over operations. Of course, it is not a good design, and we will work on 
this issue. But at least this code can be used in experiments.
Furthermore, I've shared some reflections on this feature. To avoid 
cluttering the thread, I've published them in [1]. These thoughts 
provide additional context and considerations for our ongoing work.

[1] 
https://danolivo.substack.com/p/postgresql-asymmetric-join-technique?r=34q1yy

-- 
regards, Andrei Lepikhov

Attachment

pgsql-hackers by date:

Previous
From: Ahmad Mehmood
Date:
Subject: Help regarding figuring out routes in pgAdmin4
Next
From: Chapman Flack
Date:
Subject: 'trusted'/'untrusted' PL in DoD/DISA PostgreSQL STIGs