On Wed, Jan 29, 2014 at 9:06 AM, Andrew Dunstan <and...@dunslane.net> wrote: >> I am not opposed in principle to adding new things to the counters >> struct in pg_stat_statements. I just think that the fact that the >> overhead of installing the module on a busy production system is >> currently so low is of *major* value, and therefore any person that >> proposes to expand that struct should be required to very conclusively >> demonstrate that there is no appreciably increase in overhead. Having >> a standard deviation column would be nice, but it's still not that >> important. Maybe when we have portable atomic addition we can afford >> to be much more inclusive of that kind of thing. >> > > Importance is in the eye of the beholder. As far as I'm concerned, min and > max are of FAR less value than stddev. If stddev gets left out I'm going to > be pretty darned annoyed, especially since the benchmarks seem to show the > marginal cost as being virtually unmeasurable. If those aren't enough for > you, perhaps you'd like to state what sort of tests would satisfy you.
I agree. I find it somewhat unlikely that pg_stat_statements is fragile enough that these few extra counters are going to make much of a difference. At the same time, I find min and max a dubious value proposition. It seems highly likely to me that stddev will pay its way, but I'm much less certain about the others. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
