On Wed, May 22, 2024 at 10:13 AM Jeff Davis <pg...@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
