Re: [Proposal] Add accumulated statistics - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [Proposal] Add accumulated statistics
Date
Msg-id CAFj8pRCAmu+Bk6EEmEV1fZVFfxY4+tdj6wb5U=YX1PdZgZ_UJw@mail.gmail.com
Whole thread Raw
In response to RE: [Proposal] Add accumulated statistics  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: [Proposal] Add accumulated statistics  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List 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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] generated columns
Next
From: Peter Eisentraut
Date:
Subject: Re: Displaying and dumping of table access methods