pg.ddx.io pgsql-docs@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Clarify TIMING OFF behavior 2+ messages / 2 participants [nested] [flat]
* Clarify TIMING OFF behavior @ 2013-05-19 05:03 Greg Smith <greg@2ndQuadrant.com> 2013-05-20 02:06 ` Re: Clarify TIMING OFF behavior Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 1 reply; 2+ messages in thread From: Greg Smith @ 2013-05-19 05:03 UTC (permalink / raw) To: pgsql-docs 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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs Attachments:^ permalink raw reply [nested|flat] 2+ messages in threadtiming-off-clarify.patch (text/plain, 1.2K) download
diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml index 1f35a1d..627119b 100644 --- a/doc/src/sgml/ref/explain.sgml +++ b/doc/src/sgml/ref/explain.sgml @@ -186,7 +186,8 @@ ROLLBACK; The overhead of repeatedly reading the system clock can slow down the query significantly on some systems, so it may be useful to set this parameter to <literal>FALSE</literal> when only actual row counts, and not - exact times, are needed. + exact times, are needed. Running time of the entire statement is always + collected, even when node level timing is turned off with this option. This parameter may only be used when <literal>ANALYZE</literal> is also enabled. It defaults to <literal>TRUE</literal>. </para> diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c index 38ce0ef..90fc727 100644 --- a/src/backend/commands/explain.c +++ b/src/backend/commands/explain.c @@ -414,6 +414,10 @@ ExplainOnePlan(PlannedStmt *plannedstmt, IntoClause *into, ExplainState *es, if (es->buffers) instrument_option |= INSTRUMENT_BUFFERS; + /* + * Always collect timing for the entire statement, even when + * node level timing is off. + */ INSTR_TIME_SET_CURRENT(starttime); /*
* Re: Clarify TIMING OFF behavior 2013-05-19 05:03 Clarify TIMING OFF behavior Greg Smith <greg@2ndQuadrant.com> @ 2013-05-20 02:06 ` Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2013-05-20 02:06 UTC (permalink / raw) To: Greg Smith <greg@2ndQuadrant.com>; +Cc: pgsql-docs 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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2013-05-20 02:06 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2013-05-19 05:03 Clarify TIMING OFF behavior Greg Smith <greg@2ndQuadrant.com> 2013-05-20 02:06 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox