Re: \timing interval

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: \timing interval
Дата
Msg-id CADkLM=eWXqyg9hMQU2BaND4RS+FG2=oNEjXq7bcG3qJSe4afmA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: \timing interval  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: \timing interval  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Дерево обсуждения
On Mon, Jul 11, 2016 at 8:35 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 7/9/16 4:00 PM, Andrew Gierth wrote:
How about

Time: 1234567.666 ms (20m 34.6s)

 That's similar to what I had in mind, so I'd be happy with that.


--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Ok, here's what I came up with (with time to test it).

If the query took less than a second, timing display is unchanged.
Otherwise, print the ms time, followed by a more human readable form accurate to 0.001s.

# select 1; select pg_sleep(1); select pg_sleep(71); select pg_sleep (3601); select pg_sleep(24*3601);
 ?column?
----------
        1
(1 row)

Time: 1.575 ms
 pg_sleep
----------

(1 row)

Time: 1002.568 ms (1.003s)
 pg_sleep
----------

(1 row)

Time: 71041.022 ms (1m 11.041s)
 pg_sleep
----------

(1 row)

Time: 3601083.544 ms (1h 0m 1.084s)
 pg_sleep
----------

(1 row)

Time: 86424018.416 ms (1d 0h 0m 24.018s)


As-is, there isn't much that could be done for regression or documentation changes, so I'll just leave this here.

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: rethinking dense_alloc (HashJoin) as a memory context
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: rethinking dense_alloc (HashJoin) as a memory context