Re: pg_stat_lwlocks view - lwlocks statistics
От | Satoshi Nagayasu |
---|---|
Тема | Re: pg_stat_lwlocks view - lwlocks statistics |
Дата | |
Msg-id | 4FE92550.5060805@uptime.jp обсуждение исходный текст |
Ответ на | Re: pg_stat_lwlocks view - lwlocks statistics (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: pg_stat_lwlocks view - lwlocks statistics
|
Список | pgsql-hackers |
2012/06/26 6:44, Josh Berkus wrote: > On 6/25/12 1:29 PM, Satoshi Nagayasu wrote: >> (1) Performance >> >> I've measured LWLock performance both with and without the patch, >> and confirmed that this patch does not affect the LWLock perfomance >> at all. > > This would be my main concern with this patch; it's hard for me to > imagine that it has no performance impact *at all*, since trace_lwlocks > has quite a noticable one in my experience. However, the answer to that > is to submit the patch and let people test. Thanks. I will submit the patch to the CommitFest page with some fixes to be able to work with the latest PostgreSQL on Git. > I will remark that it would be far more useful to me if we could also > track lwlocks per session. Overall counts are somewhat useful, but more > granular counts are even more useful. What period of time does the > table cover? Since last reset? Yes. it has not yet been implemented yet since this code is just a PoC one, but it is another design issue which needs to be discussed. To implement it, a new array can be added in the local process memory to hold lwlock statistics, and update counters both in the shared memory and the local process memory at once. Then, the session can retrieve 'per-session' statistics from the local process memory via some dedicated function. Does it make sense? Any comments? Regards, -- Satoshi Nagayasu <snaga@uptime.jp> Uptime Technologies, LLC. http://www.uptime.jp
В списке pgsql-hackers по дате отправления: