| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(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-11 08:34:58 |
| Message-ID: | CAFj8pRCAmu+Bk6EEmEV1fZVFfxY4+tdj6wb5U=YX1PdZgZ_UJw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
pá 11. 1. 2019 v 2:10 odesílatel Tsunakawa, Takayuki <
tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> napsal:
> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)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
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-01-11 08:36:35 | BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write |
| Previous Message | Peter Eisentraut | 2019-01-11 08:30:52 | Re: [HACKERS] generated columns |