Robert Haas escribió: > On Fri, Oct 19, 2012 at 11:52 AM, Satoshi Nagayasu <sn...@uptime.jp> wrote: > > I agree with that such performance instrument needs to be > > improved if it has critical performance issue against > > production environment. So, I'm still looking for a better > > implementation to decrease performance impact. > > Frankly, I think the approach of simply providing an "off" switch is > probably a good one. I admit that it would be nice if we could run > with instrumentation like this all the time - but until very fast > time-lookups become ubiquitous, we can't > > Another architectural problem here is that I believe this will > increase the size of the stats file, which I think is going to cause > pain for some people. I suspect that's going to be an issue even if > we have an "off" switch. I think somebody's going to have to figure > out a way to split that file up somehow.
I am closing this patch as Returned with Feedback for now. Hopefully a version can be submitted for the next commitfest with the "off" switch, but I am not sure about burdening the submitter with the responsibility of splitting the stats file. Regarding Tom's objection to the fundamental issue of providing lwlocks data, I agree that maybe it's the wrong layer to be measuring to provide data to DBAs, but not providing any data is worse, because then even PG developers cannot know what are the real bottlenecks; and it's hard to see what other layer we need to be measuring. Maybe this can serve as a foundation to discover useful things to provide in the future. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
