Kouhei Kaigai <kai...@ak.jp.nec.com> writes:
>> On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
>> <fujita.ets...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
