Re: Adding locks statistics
От | Bertrand Drouvot |
---|---|
Тема | Re: Adding locks statistics |
Дата | |
Msg-id | aJwMi6qWKNc/ygg9@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Adding locks statistics (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
Hi, On Tue, Aug 12, 2025 at 08:42:48AM -0700, Jeff Davis wrote: > On Tue, 2025-08-12 at 09:37 +0000, Bertrand Drouvot wrote: > > It can be used for example for: > > > > 1. checking if "waits" is close to "requests". Then it means you > > usually have to > > wait before acquiring the lock, which means you may have a > > concurrency issue. > > > > 2. lock_timeout and deadlock_timeout tuning (lock_timeout is visible > > only in the > > logs if log_min_error_statement is set appropriately). > > > > 3. checking the "requests"/"fastpath" ratio to see if > > "max_locks_per_transaction" > > needs tuning (see c4d5cb71d2). > > " > > > > Do these seem like useful use cases? > > Those seem plausibly useful, Thanks for sharing your thoughts about the use cases above. > and I wanted to hear more from others. > For instance, a view could be helpful to diagnose concurrency issues, > but I think that's worth discussing in more detail to see what kinds of > issues it can help with and how it complements other approaches. I > suspect when we get into the details, different people (or different > situations) would want slightly different information out of that view. Fully agree, getting input from others definitely helps validate the approach and see if the current design needs some changes. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: