Hello, At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas <robertmh...@gmail.com> wrote in <ca+tgmozrqxdtph-rpbx-frsdq+_c8u6dxctovu+zgy0hrnr...@mail.gmail.com> > On Wed, Oct 7, 2015 at 12:10 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@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. > > > > You're right. The result tuple for the Robert's example has 6 > > attributes in the order of [ft1.a, ft1.b, (ft1.a, ft1.b), ft2.a...] > > > > But the point of the discussion is in another point. The problem > > is when such joins are joined with another local table. For such > > case, the whole-row reference for the intermediate foreign-join > > would lose the targets in top-level tuple. > > Really? Would that mean that ROW_MARK_COPY is totally broken? I bet it's > not.
The semantics of ROW_MARK_COPY is the tuple should hold whole-row *value* as in resjunk column. I should misunderstood "whole row *reference*" by confising planner and executor behaviors. I understood the new story as adding to a tuple a reference to itself. If it is wrong and the correct story is having additional whole-row *value* in the whole joined tuple including resjunks passed from the underlying tuples, it should work. > >> > 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. > > > > I suppose it requires additional resjunk to be added on joinrel > > creation, which is what Kaigai-san said as overkill. But I'm > > interedted in what it looks. > > I think it rather requires *replacing* two resjunk columns by one new > one. The whole-row references for the individual foreign tables are > only there to support EvalPlanQual; if we instead have a column to > populate the foreign scan's slot directly, then we can use that column > for that purpose directly and there's no remaining use for the > whole-row vars on the baserels. It is what I had in mind. Target lists for joinrels cannot be built straight-forward way as it is. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
