(2017/11/30 23:22), Tom Lane wrote:
Etsuro Fujita<fujita.ets...@lab.ntt.co.jp> writes:
(2017/11/30 7:32), Tom Lane wrote:
the output of the foreign join cannot change during EPQ, since the remote
server already locked the rows before returning them. The only thing that
can change is the output of the local scan on public.tab. Yes, we then
need to re-verify that foo.a = tab.a ... but in this example, that's the
responsibility of the NestLoop plan node, not the foreign join.
That's right, but is that true when the FDW uses late row locking?
An FDW using late row locking would need to work harder, yes. But
that's true at the scan level as well as the join level. We have
already committed to using early locking in postgres_fdw, for the
network-round-trip-cost reasons I mentioned before, and I can't see
why we'd change that decision at the join level.
My concern is FDWs that support join pushdown in combination with late
row locking. I don't know whether such FDWs really exist, but if so, an
output of a foreign join computed from re-fetched tuples might change.
Right now we've got the worst of both worlds, in that we're actually
doing early row locking on the remote, but we're paying (some of) the
code complexity costs required for late locking.
Because we have provided the late row locking API, I think we should pay
a certain degree of consideration for such FDWs.
Best regards,
Etsuro Fujita
