From: Pavel Stehule [mailto:pavel.stehule@gmail.com] > the cumulated lock statistics maybe doesn't help with debugging - but it > is very good indicator of database (in production usage) health.
I think it will help both. But I don't think the sampling won't be as helpful as the precise lock statistics accumulation, because the sampling doesn't give us exactly how effective our improvements to PostgreSQL code are. I remember PG developers used LOCK_STATS to see how many (or ratio of) lwlock waits decreased by applying patches.
We can use the cumulated lock stats like:
1. SELECT * FROM pg_session_waits; 2. Run a benchmark. 3. SELECT * FROM pg_session_waits; 4. Calculate the difference between 1 and 3.
Or, reset the wait stats before the benchmark run and just use the stats as-is.
I'd like to know why you thought the cumulated wait stats isn't helpful for debugging.
I don't remember my thoughts, and maybe I used wrong sentences - usually lock times are very small, and very unstable if you has too detailed level. But if you use aggregated values per some longer time window, then these values can be stable and very interesting. More - usually lock time has correlation with database (application) health.
Like you I don't think so sampled values are too helpful.
