On Tue, Oct 6, 2015 at 11:30 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would have 6 > columns: those 4, plus a whole-row var for ft1 and another whole-row bar for > ft2. Maybe I'm missing something, though.
Currently, yes, but I think we should change it so that... >> 4, plus a whole-row reference for ROW_MARK_COPY. If we know what >> values we're going to store in columns 1..4, couldn't we just form >> them into a tuple to populate column 5? We don't actually need to be >> able to fetch such a tuple from the remote side because we can just >> construct it. I think. > I also was thinking whether we could replace one of the whole-row vars with > a whole-row var that represents the scan slot of the ForeignScanState node. ...it works like this instead. KaiGai is suggesting that constructing a join plan to live under the foreign scan-qua-join isn't really that difficult, but that is like saying that it's OK to go out to a nice sushi restaurant without bringing any money because it won't be too hard to talk the manager into letting you leave for a quick trip to the ATM at the end of the meal. Maybe so, maybe not, but if you plan ahead and bring money then you don't have to worry about it. The only reason why we would need the join plan in the first place is because we had the foreign scan output whole-row vars for the baserels instead of its own slot. If we have it output a var for its own slot then it doesn't matter whether constructing the join plan is easy or hard, because we don't need it. -- 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
