Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id 10176.1391038198@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add min and max execute statement time in pg_stat_statement  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Add min and max execute statement time in pg_stat_statement  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I could live with just stddev. Not sure others would be so happy.

FWIW, I'd vote for just stddev, on the basis that min/max appear to add
more to the counter update time than stddev does; you've got
this:

+         e->counters.total_sqtime += total_time * total_time;

versus this: 
+         if (e->counters.min_time > total_time || e->counters.min_time == EXEC_TIME_INIT)
+             e->counters.min_time = total_time;
+         if (e->counters.max_time < total_time)
+             e->counters.max_time = total_time;

I think on most modern machines, a float multiply-and-add is pretty
darn cheap; a branch that might or might not be taken, OTOH, is a
performance bottleneck.

Similarly, the shared memory footprint hit is more: two new doubles
for min/max versus one for total_sqtime (assuming we're happy with
the naive stddev calculation).

If we felt that min/max were of similar value to stddev then this
would be mere nitpicking.  But since people seem to agree they're
worth less, I'm thinking the cost/benefit ratio isn't there.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Failure while inserting parent tuple to B-tree is not fun