QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
- Planning time: 0.113 ms
</screen>
</para>
actually returned, updated, or deleted by the query.
</para>
- <para>
- The <literal>Planning time</literal> shown is the time it took to generate
- the query plan from the parsed query and optimize it. It does not include
- rewriting and parsing.
- </para>
-
<para>
Returning to our example:
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
- Planning time: 0.113 ms
</screen>
</para>
------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..483.00 rows=7001 width=244)
Filter: (unique1 < 7000)
- Planning time: 0.104 ms
</screen>
Notice that the <command>EXPLAIN</> output shows the <literal>WHERE</>
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
- Planning time: 0.093 ms
</screen>
Here the planner has decided to use a two-step plan: the child plan
Filter: (stringu1 = 'xxx'::name)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
- Planning time: 0.089 ms
</screen>
The added condition <literal>stringu1 = 'xxx'</literal> reduces the
-----------------------------------------------------------------------------
Index Scan using tenk1_unique1 on tenk1 (cost=0.29..8.30 rows=1 width=244)
Index Cond: (unique1 = 42)
- Planning time: 0.076 ms
</screen>
In this type of plan the table rows are fetched in index order, which
Index Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0)
Index Cond: (unique2 > 9000)
- Planning time: 0.094 ms
</screen>
But this requires visiting both indexes, so it's not necessarily a win
-> Index Scan using tenk1_unique2 on tenk1 (cost=0.29..71.27 rows=10 width=244)
Index Cond: (unique2 > 9000)
Filter: (unique1 < 100)
- Planning time: 0.087 ms
</screen>
</para>
Index Cond: (unique1 < 10)
-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244)
Index Cond: (unique2 = t1.unique2)
- Planning time: 0.117 ms
</screen>
</para>
-> Materialize (cost=0.29..8.51 rows=10 width=244)
-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..8.46 rows=10 width=244)
Index Cond: (unique2 < 10)
- Planning time: 0.119 ms
</screen>
The condition <literal>t1.hundred < t2.hundred</literal> can't be
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
- Planning time: 0.182 ms
</screen>
</para>
-> Sort (cost=197.83..200.33 rows=1000 width=244)
Sort Key: t2.unique2
-> Seq Scan on onek t2 (cost=0.00..148.00 rows=1000 width=244)
- Planning time: 0.195 ms
</screen>
</para>
-> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244)
Filter: (unique1 < 100)
-> Index Scan using onek_unique2 on onek t2 (cost=0.28..224.79 rows=1000 width=244)
- Planning time: 0.176 ms
</screen>
which shows that the planner thinks that sorting <literal>onek</> by
decisions.
</para>
+ <para>
+ The <literal>Planning time</literal> shown by <command>EXPLAIN
+ ANALYZE</command> is the time it took to generate the query plan from the
+ parsed query and optimize it. It does not include parsing or rewriting.
+ </para>
+
<para>
The <literal>Execution time</literal> shown by <command>EXPLAIN
ANALYZE</command> includes executor start-up and shut-down time, as well
<para>
Include information on the estimated startup and total cost of each
plan node, as well as the estimated number of rows and the estimated
- width of each row. Also, include the time spent planning the query,
- if available. This parameter defaults to <literal>TRUE</literal>.
+ width of each row.
+ This parameter defaults to <literal>TRUE</literal>.
</para>
</listitem>
</varlistentry>
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo (cost=0.00..155.00 rows=10000 width=4)
- Planning time: 0.114 ms
-(2 rows)
+(1 row)
</programlisting>
</para>
"Total Cost": 155.00, +
"Plan Rows": 10000, +
"Plan Width": 4 +
- }. +
- "Planning Time": 0.114 +
+ } +
} +
]
(1 row)
--------------------------------------------------------------
Index Scan using fi on foo (cost=0.00..5.98 rows=1 width=4)
Index Cond: (i = 4)
- Planning time: 0.073 ms
-(3 rows)
+(2 rows)
</programlisting>
</para>
Total Cost: 5.98 +
Plan Rows: 1 +
Plan Width: 4 +
- Index Cond: "(i = 4)" +
- Planning Time: 0.073
+ Index Cond: "(i = 4)"
(1 row)
</programlisting>
Aggregate (cost=23.93..23.93 rows=1 width=4)
-> Index Scan using fi on foo (cost=0.00..23.92 rows=6 width=4)
Index Cond: (i < 10)
- Planning time: 0.088 ms
(3 rows)
</programlisting>
</para>
Index Cond: ((id > $1) AND (id < $2))
Planning time: 0.197 ms
Execution time: 0.225 ms
-(5 rows)
+(6 rows)
</programlisting>
</para>
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("EXPLAIN option TIMING requires ANALYZE")));
+ /* currently, summary option is not exposed to users; just set it */
+ es.summary = es.analyze;
+
/*
* Parse analysis was done already, but we still have to run the rule
* rewriter. We do not do AcquireRewriteLocks: we assume the query either
/*
* We always collect timing for the entire statement, even when node-level
- * timing is off, so we don't look at es->timing here.
+ * timing is off, so we don't look at es->timing here. (We could skip
+ * this if !es->summary, but it's hardly worth the complication.)
*/
INSTR_TIME_SET_CURRENT(starttime);
/* Create textual dump of plan tree */
ExplainPrintPlan(es, queryDesc);
- if (es->costs && planduration)
+ if (es->summary && planduration)
{
double plantime = INSTR_TIME_GET_DOUBLE(*planduration);
totaltime += elapsed_time(&starttime);
- if (es->analyze)
+ if (es->summary)
{
if (es->format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es->str, "Execution time: %.3f ms\n",
projects / postgresql / commitdiff