I considered pg_stat_locks, but chose the singular form to be consistent with pg_stat_database, pg_stat_subscription, and friends.
Counter-examples: pg_stat_statements, pg_stat_subscription_stats. Our names are not consistent. :) It just feels a better fit to have a plural name for a table tracking aggregates of multiple types of objects.
(Ignore my git complaint, was obviously half-asleep when I wrote that).
> Docs: seem good. Needs a section on how to reset via > SELECT pg_stat_reset_shared('lock');
I meant something closer to the actual description of the view. Having it buried in the pg_stat_reset_shared section is not intuitive for people looking up the view in the docs.
Because it looks like that they are ordered by alphabetical order.
That makes sense.
- I'm not sure that's worth for this particular case and code paths.
Will let others opine on that.
Thanks! Did you observe some noticeable performance penalties?
No, but I did not give it any particularly heavy testing. More of a idle thought when pulling up a brand new system and seeing the thousands of locks for the tiniest bit of database action.
