Hi,
At Fri, 9 Oct 2015 12:00:30 +0900, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote in
<56172DCE.7080604@lab.ntt.co.jp>
> On 2015/10/08 19:55, Etsuro Fujita wrote:
> > I noticed that the approach using a column to populate the foreign
> > scan's slot directly wouldn't work well in some cases. For example,
> > consider:
> >
> > SELECT * FROM verysmall v LEFT JOIN (bigft1 JOIN bigft2 ON bigft1.x =
> > bigft2.x) ON v.q = bigft1.q AND v.r = bigft2.r FOR UPDATE OF v;
>
> Oops, I should have written "JOIN", not "LEFT JOIN".
>
> > The best plan is presumably something like this as you said before:
> >
> > LockRows
> > -> Nested Loop
> > -> Seq Scan on verysmall v
> > -> Foreign Scan on bigft1 and bigft2
> > Remote SQL: SELECT * FROM bigft1 JOIN bigft2 ON bigft1.x =
> > bigft2.x AND bigft1.q = $1 AND bigft2.r = $2
> >
> > Consider the EvalPlanQual testing to see if the updated version of a
> > tuple in v satisfies the query. If we use the column in the testing,
> > we
> > would get the wrong results in some cases.
>
> More precisely, we would get the wrong result when the value of v.q or
> v.r in the updated version has changed.
What do you think the right behavior?
Assuming that it is simply a join between local tables.
SELECT * FROM t1 JOIN t2 on (t1.a = t2.a) FOR UPDATE;
IIUC, if t1.a gets updated and EPQ runs, the tuple for t1 is
refetched using ctid and that for t2 reused, so it would fail to
be qualified and the joined tuple won't be returned.
What happens on the foreign join example seems to be exactly the
same thing.
> I don't have a good idea for this, so would an approach using an local
> join execution plan be the good way to go?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center