út 15. 1. 2019 v 2:14 odesílatel Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> napsal:
> From: Pavel Stehule [mailto:pavel.steh...@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. Regards Pavel > > Regards > Takayuki Tsunakawa > > >
