Subject: Re: Skip adding row-marks for non target tables when result relation is foreign table.

From: Etsuro Fujita <[email-masked]>
Date: Fri, 9 Aug 2024 17:35:11 +0900

On Wed, May 22, 2024 at 10:13 AM Jeff Davis <[email-masked]> 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

---

From: Jeff Davis <[email-masked]>
Date: Wed, 14 Aug 2024 17:56:46 -0700

> ExecLockRows(), so I think the overhead is caused in the normal case.

Is there any sample code that implements late locking for a FDW? I'm
not quite clear on how it's supposed to work.

Regards,
	Jeff Davis

---

From: Etsuro Fujita <[email-masked]>
Date: Thu, 15 Aug 2024 20:45:44 +0900

> not quite clear on how it's supposed to work.

See the patch in [1].  It would not apply to HEAD anymore, though.

Best regards,
Etsuro Fujita

[1] https://www.postgresql.org/message-id/[email-masked]