Re: Foreign join pushdown vs EvalPlanQual

Hello,

At Fri, 9 Oct 2015 18:40:32 +0900, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <56178B90(dot)4030206(at)lab(dot)ntt(dot)co(dot)jp>
> > What do you think the right behavior?

# 'is' was omitted..

> IIUC, I think that the foreign scan's slot should be set empty, that

Even for the case, EvalPlanQualFetchRowMarks retrieves tuples of
remote tables out of the whole-row resjunks and set them to
es_epqTuple[] so that EvalPlanQualNext can use it. The behavior
is not different from the 'FOR UPDATE;' (for all tables) cases.

I supposed that whole-row value for the joined tuple would be
treated in the same manner to the case of the tuples of base
foreign relations.

This is because preprocess_rowmarks makes rowMarks of the type
LCS_NONE for the relations other than the designated by "OF
colref" for "FOR UPDATE". Then it is converted into ROW_MARK_COPY
by select_rowmark_type, which causes the behavior above, as the
default behavior for foreign tables.

> the join should fail, and that the updated version of the tuple in v
> should be ignored in that scenario since that for the updated version
> of the tuple in v, the tuples obtained from those two foreign tables
> wouldn't satisfy the remote query.

AFAICS, no updated version for remote tables are obtained.

Even though the behavior I described above is correct, the join
would fail, too. But it is because v.r is no longer equal to
bigft2.r in the whole-row-var tuples. This seems seemingly the
same behavior with that on local tables.

# LCS_NONE for local tables is converted into ROW_MARK_COPY if no
# securityQuals are attached.

> But if populating the foreign
> scan's slot from that column, then the join would success and the
> updated version of the tuple in v would be returned wrongly, I think.

I might understand wrongly in some points..

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center