RE: [Proposal] Add accumulated statistics

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: [Proposal] Add accumulated statistics
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FB66610@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: [Proposal] Add accumulated statistics  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы RE: [Proposal] Add accumulated statistics  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Re: [Proposal] Add accumulated statistics  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
From: Pavel Stehule [mailto:pavel.stehule@gmail.com]
> the cumulated lock statistics maybe doesn't help with debugging - but it
> is very good indicator of database (in production usage) health.

I think it will help both.  But I don't think the sampling won't be as helpful as the precise lock statistics
accumulation,because the sampling doesn't give us exactly how effective our improvements to PostgreSQL code are.  I
rememberPG developers used LOCK_STATS to see how many (or ratio of) lwlock waits decreased by applying patches.
 


We can use the cumulated lock stats like:

1. SELECT * FROM pg_session_waits;
2. Run a benchmark.
3. SELECT * FROM pg_session_waits;
4. Calculate the difference between 1 and 3.

Or, reset the wait stats before the benchmark run and just use the stats as-is.

I'd like to know why you thought the cumulated wait stats isn't helpful for debugging.


Regards
Takayuki Tsunakawa



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Reducing header interdependencies around heapam.h et al.