On Mon, 18 Aug 2025 at 15:13, James Pang <jamespang...@gmail.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
