On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu <sn...@uptime.jp> wrote: > HEAD > ==== > number of transactions actually processed: 3439971 > tps = 57331.891602 (including connections establishing) > tps = 57340.932324 (excluding connections establishing) <snip> > pg_stat_lwlocks patch (reporting disabled) > ========================================== > number of transactions actually processed: 3429370 > tps = 57155.286475 (including connections establishing) > tps = 57163.996943 (excluding connections establishing) > > So, I think some additional hack to reduce reporting is needed. > Would it be acceptable in terms of the performance?
The tracing lwlock usage seems to still cause a small performance overhead even if reporting is disabled. I believe some users would prefer to avoid such overhead even if pg_stat_lwlocks is not available. It should be up to a user to decide whether to trace lwlock usage, e.g., by using trace_lwlock parameter, I think. >> Another comment is; local_calls/waits/time_ms are really required? >> I'm not sure how those info would help the performance debugging. > > > I think there are some needs to observe/determine how your test > query is affected by the other workload from the other sessions. > So, splitting local and shared statistics would be nice to have. > Just my thought though. What I don't like is that a session can see only local stats of its own session. It's hard to monitor local stats. Imagine the case where you'd like to monitor local stats of each pgbench session. To monitor such stats, you need to modify pgbench so that its each session monitors its own local stats. Even if you run a monitoring software, it cannot collect those stats because they don't belong to the session that it uses. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
