> Kouhei Kaigai <kaigai@ak.jp.nec.com> writes:
> >> On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
> >> <fujita.etsuro@lab.ntt.co.jp> wrote:
> >> I don't see how this can be right. You're basically just pretending
> >> EPQ doesn't exist in the remote join case, which isn't going to work
> >> at all. Those bits of code that look at es_epqTuple, es_epqTupleSet,
> >> and es_epqScanDone are not optional. You can't just skip over those
> >> as if they don't matter.
>
> > I think, it is right approach to pretend EPQ doesn't exist if scanrelid==0,
> > because what replaced by these ForeignScan/CustomScan node are local join
> > node like NestLoop.
>
> That's just nonsense. The reason that nestloop doesn't need its own EPQ
> slot is that what it will be joining is tuples provided by scan nodes,
> and it was the scan nodes that took care of fetching correct,
> updated-if-need-be tuples for the EPQ check. You can't just discard that
> responsibility when you're implementing a join remotely ... at least not
> if you want to preserve semantics similar to what happens with local
> tables.
>
NestLoop itself does not need its own EPQ slot, no doubt. However,
entire sub-tree of NestLoop takes at least two underlying EPQ slots
of the base relations to be joined.
My opinion is, simply, ForeignScan/CustomScan with scanrelid==0 takes
over the responsibility of EPQ recheck of entire join sub-tree that is
replaced by the ForeignScan/CustomScan node.
If ForeignScan run a remote join on foreign tables: A and B, it shall
apply both of scan-quals and join-clause towards the tuples kept in
the EPQ slots, in some fashion depending on FDW implementation.
Nobody concerned about what check shall be applied here. EPQ recheck
shall be applied as if entire join sub-tree exists here.
Major difference between I and Fujita-san is how to recheck it.
I think FDW knows the best way to do (even if we can provide utility
routines for majority cases), however, Fujita-san says a particular
implementation is the best for all the people. I cannot agree with
his opinion.
> Or maybe I misunderstood what you meant, but it's certainly not OK to say
> that EPQ is a no-op for a pushed-down join. Rather, it has to perform all
> the same checks that would have happened for any of its constitutent
> tables.
>
I've never said that EPQ should be no-op for a pushed-down join.
Responsibility of the entire join sub-tree is not discarded, and
not changed, even if it is replaced by a remote-join.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
