Re: Foreign join pushdown vs EvalPlanQual

>> On 2015/10/15 11:36, Kouhei Kaigai wrote:
>>> In case of scanrelid==0, expectation to ForeignScan/CustomScan is to
>>> behave as if local join exists here. It requires ForeignScan to generate
>>> joined-tuple as a result of remote join, that may contains multiple junk
>>> TLEs to carry whole-var references of base foreign tables.
>>> According to the criteria, the desirable behavior is clear as below:
>>>
>>> 1. FDW/CSP picks up base relation's tuple from the EPQ slots.
>>>      It shall be setup by whole-row reference if earlier row-lock semantics,
>>>      or by RefetchForeignRow if later row-lock semantics.
>>>
>>> 2. Fill up ss_ScanTupleSlot according to the xxx_scan_tlist.
>>>      We may be able to provide a common support function here, because this
>>>      list keeps relation between a particular attribute of the joined-tuple
>>>      and its source column.
>>>
>>> 3. Apply join-clause and base-restrict that were pushed down.
>>>      setrefs.c initializes expressions kept in fdw_exprs/custom_exprs to run
>>>      on the ss_ScanTupleSlot. It is the easiest way to check here.
>>>
>>> 4. If joined-tuple is still visible after the step 3, FDW/CSP returns
>>>      joined-tuple. Elsewhere, returns an empty slot.
>>>
>>> It is entirely compatible behavior even if local join is located on
>>> the point of ForeignScan/CustomScan with scanrelid==0.
>>>
>>> Even if remote join is parametalized by other relation, we can simply
>>> use param-info delivered from the corresponding outer scan at the step-3.
>>> EState should have the parameters already updated, FDW driver needs to
>>> care about nothing.
>>>
>>> It is quite less invasive approach towards the existing EPQ recheck
>>> mechanism.

I wrote:
>> I see.  That's an idea, but I guess that step 2 and 3 would need to add
>> a lot of code to the core.  Why don't you use a local join execution
>> plan that we discussed?  I think that that would make the series of
>> processing much simpler.  I'm now revising the patch that I created for
>> that.  If it's okay, I'd like to propose an updated version of the patch
>> in a few days.

On 2015/10/15 20:19, Kouhei Kaigai wrote:
> I have to introduce why above idea is simpler and suitable for v9.5
> timeline.
> As I've consistently proposed for this two months, the step-2 and 3
> are assumed to be handled in the callback routine to be kicked from
> ForeignRecheck().

Honestly, I still don't think I would see the much value in doing so.
As Robert mentioned in [1], I think that if we're inside EPQ,
pushed-down quals and/or pushed-down joins should be locally rechecked
in the same way as other cases such as IndexRecheck.  So, I'll propose
the updated version of the patch.

Thanks for the explanation!

Best regards,
Etsuro Fujita

[1]
http://www.postgresql.org/message-id/CA+Tgmoau7jVTLF0Oh9a_Mu9S=vrw7i6u_h7JSpzBXv0xtyo_Bg@mail.gmail.com