Robert Haas <robertmh...@gmail.com> writes: > 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.
There are multiple components to the requirement though: 1. Recheck the rows that were in the baserels and possibly fetch updated versions of them. (Once we're in EPQ, we want the most recent row versions, not what the query snapshot can see.) 2. Apply relevant restriction clauses and see if the updated row versions still pass the clauses. 3. If so, form a join row and return that. Else return NULL. One way or another, the FDW has to do all of the above, or as much of it as it can't fob off on the remote server, once it's decided to bypass local implementation of the join. Just recomputing the original join row is *not* good enough. I think what Kaigai-san and Etsuro-san are after is trying to find a way to reuse some of the existing EPQ machinery to help with that. This may not be practical, or it may end up being messier than a standalone implementation; but it's not silly on its face to want to reuse some of that code. 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