Re: [Proposal] Add accumulated statistics

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>

To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.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-11T08:34:58Z

Lists: pgsql-hackers

pá 11. 1. 2019 v 2:10 odesílatel Tsunakawa, Takayuki <
tsunakawa.takay@jp.fujitsu.com> napsal:

> From: Robert Haas [mailto:robertmhaas@gmail.com]
> > My theory is that the number of wait events is NOT useful information,
> > or at least not nearly as useful the results of a sampling approach.
> > The data that LWLOCK_STATS produce are downright misleading -- they
> > lead you to think that the bottlenecks are in different places than
> > they really are, because the locks that produce the most waiting can
> > be 5th or 10th in terms of the number of wait events.
>
> I understood you're saying that the number of waits alone does not
> necessarily indicate the bottleneck, because a wait with fewer counts but
> longer time can take a large portion of the entire SQL execution time.  So,
> wait time is also useful.  I think that's why Oracle describes and MySQL
> provides precise count and time without sampling.
>

the cumulated lock statistics maybe doesn't help with debugging - but it is
very good indicator of database (in production usage) health.

Regards

Pavel


>
>