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

From Robert Haas
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id CA+TgmobgGHb_92adFnG7kBb44Ad-H7dAGeeUt2Ru=98Tb8g_bw@mail.gmail.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add min and max execute statement time in pg_stat_statement
Re: Add min and max execute statement time in pg_stat_statement
Re: Add min and max execute statement time in pg_stat_statement
List pgsql-hackers
On Mon, Oct 21, 2013 at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Gavin Flower <GavinFlower@archidevsys.co.nz> writes:
>>>> If we're going to extend pg_stat_statements, even more than min and max
>>>> I'd like to see the standard deviation in execution time.
>
>> How about the 'median', often a lot more useful than the 'arithmetic
>> mean' (which most people call the 'average').
>
> AFAIK, median is impossible to calculate cheaply (in particular, with
> a fixed amount of workspace).  So this apparently innocent request
> is actually moving the goalposts a long way, because the space per
> query table entry is a big concern for pg_stat_statements.

Yeah, and I worry about min and max not being very usable - once they
get pushed out to extreme values, there's nothing to drag them back
toward normality except resetting the stats, and that's not something
we want to encourage people to do frequently. Of course, averages over
very long sampling intervals may not be too useful anyway, dunno.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Peter Geoghegan
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement