On Tue, Oct 6, 2015 at 11:30 PM, Etsuro Fujita
<fujita.etsuro@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
