On 01/29/2014 04:14 PM, Peter Geoghegan wrote:
On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan <and...@dunslane.net> wrote:
mportance 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 certainly agree that stddev is far more valuable than min and max.
I'd be inclined to not accept the latter on the grounds that they
aren't that useful.
So, am I correct in my understanding: The benchmark performed here [1]
was of a standard pgbench SELECT workload, with no other factor
influencing the general overhead (unlike the later test that queried
pg_stat_statements as well)? I'd prefer to have seen the impact on a
32 core system, where spinlock contention would naturally be more
likely to appear, but even still I'm duly satisfied.
I could live with just stddev. Not sure others would be so happy.
Glad we're good on the performance impact front.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
