Re: Add min and max execute statement time in pg_stat_statement
От | Robert Haas |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | CA+TgmoZ9JVktP0=nhBH=mui_d2UVY4vFRrMaEMV_WqR_XQYaJw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
On Mon, Apr 7, 2014 at 4:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> I just noticed that this patch not only adds min,max,stddev, but it also >> adds the ability to reset an entry's counters. This hasn't been >> mentioned in this thread at all; there has been no discussion on whether >> this is something we want to have, nor on whether this is the right API. > >> What it does is add a new function pg_stat_statements_reset_time() which >> resets the min and max values from all function's entries, without >> touching the stddev state variables nor the number of calls. Note >> there's no ability to reset the values for a single function. > > That seems pretty bizarre. At this late date, the best thing would > probably be to strip out the undiscussed functionality. It can get > resubmitted for 9.5 if there's a real use-case for it. If I'm understanding correctly, that actually seems reasonably sensible. I mean, the big problem with min/max is that you might be taking averages and standard deviations over a period of months, but the maximum and minimum are not that meaningful over such a long period. You might well want to keep a longer-term average while seeing the maximum and minimum for, say, today. I don't know exactly how useful that is, but it doesn't seem obviously dumb. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: