| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Pavel Stehule' <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, "Phil Florent" <philflorent(at)hotmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: [Proposal] Add accumulated statistics |
| Date: | 2019-01-15 01:13:40 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB66610@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Pavel Stehule [mailto:pavel(dot)stehule(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-01-15 01:22:07 | Re: Reducing header interdependencies around heapam.h et al. |
| Previous Message | David Rowley | 2019-01-15 00:55:45 | Re: "SELECT ... FROM DUAL" is not quite as silly as it appears |