On Fri, Oct 16, 2015 at 7:48 PM, Kouhei Kaigai <kai...@ak.jp.nec.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
