RE: [Proposal] Add accumulated statistics

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>

To: 'Pavel Stehule' <pavel.stehule@gmail.com>

Cc: Robert Haas <robertmhaas@gmail.com>, "Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>, Bruce Momjian <bruce@momjian.us>, "Phil Florent" <philflorent@hotmail.com>, Michael Paquier <michael@paquier.xyz>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>

Date: 2019-01-15T01:13:40Z

Lists: pgsql-hackers

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.


Regards
Takayuki Tsunakawa