| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com> |
| Cc: | 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 01:09:16 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB654A6@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Haven't LOCK_STATS been helpful for PG developers? IIRC, it was used to pinpoint the bottleneck and evaluate the patch to improve shared buffers, WAL buffers, ProcArray, etc.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-01-11 01:14:13 | Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name |
| Previous Message | Michael Paquier | 2019-01-11 01:09:04 | Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name |