Обсуждение: Clarify TIMING OFF behavior

Поиск
Список
Период
Сортировка

Clarify TIMING OFF behavior

От
Greg Smith
Дата:
While chatting in #pedant today, I noticed that it's not clear that
EXPLAIN (ANALYZE ON, TIMING OFF) will still collect the total runtime of
the statement.  Attached patch clarifies that.  It also comments why the
related code runs INSTR_TIME_SET_CURRENT in all cases.  That's actually
how I noticed that--a read through explain.c now could rightly wonder
"why is it still collecting that bit of time info when TIMING is off?"

There's an argument possible here that a third TIMING option besides
ON/OFF should really exist, one that really doesn't do any timing at
all.  I don't think enough use cases for that exist to justify coding
it.  The low overhead combination I've wanted for a while is EXPLAIN
(ANALYZE ON, BUFFERS ON, TIMING OFF), and that works.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

Вложения

Re: Clarify TIMING OFF behavior

От
Tom Lane
Дата:
Greg Smith <greg@2ndQuadrant.com> writes:
> While chatting in #pedant today, I noticed that it's not clear that
> EXPLAIN (ANALYZE ON, TIMING OFF) will still collect the total runtime of
> the statement.  Attached patch clarifies that.  It also comments why the
> related code runs INSTR_TIME_SET_CURRENT in all cases.  That's actually
> how I noticed that--a read through explain.c now could rightly wonder
> "why is it still collecting that bit of time info when TIMING is off?"

Applied with a little bit of further wordsmithing.

> There's an argument possible here that a third TIMING option besides
> ON/OFF should really exist, one that really doesn't do any timing at
> all.  I don't think enough use cases for that exist to justify coding
> it.

Agreed.  If you can't tolerate two gettimeofday calls per EXPLAIN,
you don't need a new EXPLAIN option ... you need new hardware.

            regards, tom lane