Re: Skip adding row-marks for non target tables when result relation is foreign table. - Mailing list pgsql-hackers

On Wed, May 22, 2024 at 10:13 AM Jeff Davis <pgsql@j-davis.com> wrote:
> On Mon, 2024-05-06 at 23:10 +0100, SAIKIRAN AVULA wrote:
> >  Additionally, the commit afb9249d06f47d7a6d4a89fea0c3625fe43c5a5d,
> > which introduced late locking for foreign tables, mentions that the
> > benefits of late locking against a remote server are unclear, as the
> > extra round trips required are likely to outweigh any potential
> > concurrency improvements.
>
> The extra round trip only happens when EPQ finds a newer version of the
> tuple, which should be the exceptional case. I'm not sure how this
> balances out, but to me late locking still seems preferable. Early
> locking is a huge performance hit in some cases (locking many more rows
> than necessary).

I might be missing something, but I think the extra round trip happens
for each foreign row locked using the RefetchForeignRow() API in
ExecLockRows(), so I think the overhead is caused in the normal case.

> Early locking is also a violation of the documentation here:
>
> "When a locking clause appears at the top level of a SELECT query, the
> rows that are locked are exactly those that are returned by the query;
> in the case of a join query, the rows locked are those that contribute
> to returned join rows."

Yeah, but I think this holds true for SELECT queries postgres_fdw
sends to the remote side.  :)

Best regards,
Etsuro Fujita