RE: [Proposal] Add accumulated statistics
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: [Proposal] Add accumulated statistics |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB654A6@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: [Proposal] Add accumulated statistics (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [Proposal] Add accumulated statistics
|
Список | pgsql-hackers |
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 withfewer 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 toimprove shared buffers, WAL buffers, ProcArray, etc. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: