Re: max_locks_per_transaction v18

not tested and any regression found either, with 10k connections, and
"max_locks_per_transaction=128", it need about more than 1GB extra
memory,right? per my understanding, max_locks_per_transaction is the max
locked objects in a transaction (that's not an average locked objects at
the same time among all connections), but for past-path-lock slots, the
memory will be allocated based on this parameter after client connection
established, right? so, even no so many fast lock slots needed, for 10k
connections, extra memory got allocated there. We may test that in our
environment, and update then if anything found.

James

David Rowley <dgrowleyml(at)gmail(dot)com> 於 2025年8月18日週一 下午2:09寫道：

> On Mon, 18 Aug 2025 at 15:13, James Pang <jamespang886(at)gmail(dot)com> wrote:
> > We are planning to database upgrade, and evaluate PGv18 as next new
> major version. Based on new release notes, one question about, "Improve the
> locking performance of queries that access many relations ".
> > new share_lock_table size is based on max_locks_per_transaction, our
> production databases have 8k-10k connections, and existing PGV14 stable
> running there long time. Is it possible to get a new GUC instead of
> reusing "max_locks_per_transaction", so we can more flexible control on our
> production environment, for example, we want to keep similar value as
> existing "shared_lock_table" size related, and separate control of
> "max_locks_per_transaction".
>
> What do you have max_locks_per_transaction set to?
>
> Can you demonstrate that having a separate GUC for the fast-path
> locking slots is useful? Have you benchmarked this? If so, I suspect
> the results of that will be more likely to convince us than an
> evidence-less request.
>
> One thing to note is that the change Tomas made will never result in
> there before fewer fastpath locking slots than there were previously,
> so I doubt you'll find any regressions here, which might mean there's
> not much chance we'll adjust this at this hour for v18.
>
> David
>