Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id 52E90AF3.8010904@dunslane.net
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Add min and max execute statement time in pg_stat_statement  (Robert Haas <robertmhaas@gmail.com>)
Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 01/29/2014 02:58 AM, Peter Geoghegan 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.

cheers

andrew






pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)