pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <greg@2ndQuadrant.com>
To: pgsql-docs <pgsql-docs@postgresql.org>
Subject: Clarify TIMING OFF behavior
Date: Sun, 19 May 2013 01:03:45 -0400
Message-ID: <51985D31.1030705@2ndQuadrant.com> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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:

timing-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); /*

view thread (2+ messages)  latest in thread

Message-ID: <51985D31.1030705@2ndQuadrant.com>
Permalink:  ../51985D31.1030705@2ndQuadrant.com/
Also on:    postgresql.org/message-id/51985D31.1030705@2ndQuadrant.com

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-docs@postgresql.org
  Cc: greg@2ndQuadrant.com
  Subject: Re: Clarify TIMING OFF behavior
  In-Reply-To: <51985D31.1030705@2ndQuadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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