Satoshi Nagayasu <sn...@uptime.jp> writes: > (2012/10/14 13:26), Fujii Masao wrote: >> 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.
> Frankly speaking, I do not agree with disabling performance > instrument to improve performance. DBA must *always* monitor > the performance metrix when having such heavy workload. This brings up a question that I don't think has been honestly considered, which is exactly whom a feature like this is targeted at. TBH I think it's of about zero use to DBAs (making the above argument bogus). It is potentially of use to developers, but a DBA is unlikely to be able to do anything about lwlock-level contention even if he has the knowledge to interpret the data. So I feel it isn't something that should be turned on in production builds. I'd vote for enabling it by a non-default configure option, and making sure that it doesn't introduce any overhead when the option is off. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers