Re: Foreign join pushdown vs EvalPlanQual

On Fri, Oct 16, 2015 at 7:48 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> 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.

And my opinion, as I said before, is that's completely wrong. The
ForeignScan which represents a pushed-down join is a *scan*. In
general, scans have one EPQ slot, and that is the right number. This
pushed-down join scan, though, is in a state of confusion. The code
that populates the EPQ slots thinks it's got multiple slots, one per
underlying relation. Meanwhile, the code that reads data back out of
those slots thinks it doesn't have any slots at all. Both of those
pieces of code are wrong. This foreign scan, like any other scan,
should use ONE slot.

Both you and Etsuro Fujita are proposing to fix this problem by
somehow making it the FDW's problem to reconstruct the tuple
previously produced by the join from whole-row images of the baserels.
But that's not looking back far enough: why are we asking for
whole-row images of the baserels when what we really want is a
whole-row image of the output of the join? The output of the join is
what we need to re-return.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company