From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com |
Cc: | kaigai(at)ak(dot)jp(dot)nec(dot)com, pgsql-hackers(at)postgresql(dot)org, shigeru(dot)hanada(at)gmail(dot)com |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-10-09 03:00:30 |
Message-ID: | 56172DCE.7080604@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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?
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-10-09 03:04:46 | Re: Multi-tenancy with RLS |
Previous Message | Stephen Frost | 2015-10-09 02:48:11 | Re: RLS bug in expanding security quals |