@@ -89,6 +89,7 @@ EXPLAIN SELECT * FROM tenk1;
8989 QUERY PLAN
9090-------------------------------------------------------------
9191 Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
92+ Planning time: 0.113 ms
9293</screen>
9394 </para>
9495
@@ -161,6 +162,12 @@ EXPLAIN SELECT * FROM tenk1;
161162 actually returned, updated, or deleted by the query.
162163 </para>
163164
165+ <para>
166+ The <literal>Planning time</literal> shown is the time it took to generate
167+ the query plan from the parsed query and optimize it. It does not include
168+ rewriting and parsing.
169+ </para>
170+
164171 <para>
165172 Returning to our example:
166173
@@ -170,6 +177,7 @@ EXPLAIN SELECT * FROM tenk1;
170177 QUERY PLAN
171178-------------------------------------------------------------
172179 Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
180+ Planning time: 0.113 ms
173181</screen>
174182 </para>
175183
@@ -198,6 +206,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000;
198206------------------------------------------------------------
199207 Seq Scan on tenk1 (cost=0.00..483.00 rows=7001 width=244)
200208 Filter: (unique1 < 7000)
209+ Planning time: 0.104 ms
201210</screen>
202211
203212 Notice that the <command>EXPLAIN</> output shows the <literal>WHERE</>
@@ -234,6 +243,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;
234243 Recheck Cond: (unique1 < 100)
235244 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
236245 Index Cond: (unique1 < 100)
246+ Planning time: 0.093 ms
237247</screen>
238248
239249 Here the planner has decided to use a two-step plan: the child plan
@@ -262,6 +272,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND stringu1 = 'xxx';
262272 Filter: (stringu1 = 'xxx'::name)
263273 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
264274 Index Cond: (unique1 < 100)
275+ Planning time: 0.089 ms
265276</screen>
266277
267278 The added condition <literal>stringu1 = 'xxx'</literal> reduces the
@@ -283,6 +294,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 = 42;
283294-----------------------------------------------------------------------------
284295 Index Scan using tenk1_unique1 on tenk1 (cost=0.29..8.30 rows=1 width=244)
285296 Index Cond: (unique1 = 42)
297+ Planning time: 0.076 ms
286298</screen>
287299
288300 In this type of plan the table rows are fetched in index order, which
@@ -311,6 +323,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;
311323 Index Cond: (unique1 < 100)
312324 -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0)
313325 Index Cond: (unique2 > 9000)
326+ Planning time: 0.094 ms
314327</screen>
315328
316329 But this requires visiting both indexes, so it's not necessarily a win
@@ -331,6 +344,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000 LIMIT 2
331344 -> Index Scan using tenk1_unique2 on tenk1 (cost=0.29..71.27 rows=10 width=244)
332345 Index Cond: (unique2 > 9000)
333346 Filter: (unique1 < 100)
347+ Planning time: 0.087 ms
334348</screen>
335349 </para>
336350
@@ -364,6 +378,7 @@ WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2;
364378 Index Cond: (unique1 < 10)
365379 -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244)
366380 Index Cond: (unique2 = t1.unique2)
381+ Planning time: 0.117 ms
367382</screen>
368383 </para>
369384
@@ -415,6 +430,7 @@ WHERE t1.unique1 < 10 AND t2.unique2 < 10 AND t1.hundred < t2.hundred;
415430 -> Materialize (cost=0.29..8.51 rows=10 width=244)
416431 -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..8.46 rows=10 width=244)
417432 Index Cond: (unique2 < 10)
433+ Planning time: 0.119 ms
418434</screen>
419435
420436 The condition <literal>t1.hundred < t2.hundred</literal> can't be
@@ -462,6 +478,7 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
462478 Recheck Cond: (unique1 < 100)
463479 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
464480 Index Cond: (unique1 < 100)
481+ Planning time: 0.182 ms
465482</screen>
466483 </para>
467484
@@ -492,6 +509,7 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
492509 -> Sort (cost=197.83..200.33 rows=1000 width=244)
493510 Sort Key: t2.unique2
494511 -> Seq Scan on onek t2 (cost=0.00..148.00 rows=1000 width=244)
512+ Planning time: 0.195 ms
495513</screen>
496514 </para>
497515
@@ -528,6 +546,7 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
528546 -> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244)
529547 Filter: (unique1 < 100)
530548 -> Index Scan using onek_unique2 on onek t2 (cost=0.28..224.79 rows=1000 width=244)
549+ Planning time: 0.176 ms
531550</screen>
532551
533552 which shows that the planner thinks that sorting <literal>onek</> by
@@ -564,6 +583,7 @@ WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2;
564583 Index Cond: (unique1 < 10)
565584 -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244) (actual time=0.021..0.022 rows=1 loops=10)
566585 Index Cond: (unique2 = t1.unique2)
586+ Planning time: 0.181 ms
567587 Total runtime: 0.501 ms
568588</screen>
569589
@@ -612,6 +632,7 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2 ORDER BY t1.fivethous;
612632 Recheck Cond: (unique1 < 100)
613633 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.049..0.049 rows=100 loops=1)
614634 Index Cond: (unique1 < 100)
635+ Planning time: 0.194 ms
615636 Total runtime: 8.008 ms
616637</screen>
617638
@@ -635,6 +656,7 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE ten < 7;
635656 Seq Scan on tenk1 (cost=0.00..483.00 rows=7000 width=244) (actual time=0.016..5.107 rows=7000 loops=1)
636657 Filter: (ten < 7)
637658 Rows Removed by Filter: 3000
659+ Planning time: 0.083 ms
638660 Total runtime: 5.905 ms
639661</screen>
640662
@@ -657,6 +679,7 @@ EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)';
657679 Seq Scan on polygon_tbl (cost=0.00..1.05 rows=1 width=32) (actual time=0.044..0.044 rows=0 loops=1)
658680 Filter: (f1 @> '((0.5,2))'::polygon)
659681 Rows Removed by Filter: 4
682+ Planning time: 0.040 ms
660683 Total runtime: 0.083 ms
661684</screen>
662685
@@ -675,6 +698,7 @@ EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)';
675698 Index Scan using gpolygonind on polygon_tbl (cost=0.13..8.15 rows=1 width=32) (actual time=0.062..0.062 rows=0 loops=1)
676699 Index Cond: (f1 @> '((0.5,2))'::polygon)
677700 Rows Removed by Index Recheck: 1
701+ Planning time: 0.034 ms
678702 Total runtime: 0.144 ms
679703</screen>
680704
@@ -705,6 +729,7 @@ EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique
705729 -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0) (actual time=0.227..0.227 rows=999 loops=1)
706730 Index Cond: (unique2 > 9000)
707731 Buffers: shared hit=5
732+ Planning time: 0.088 ms
708733 Total runtime: 0.423 ms
709734</screen>
710735
@@ -732,6 +757,7 @@ EXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 < 100;
732757 Recheck Cond: (unique1 < 100)
733758 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1)
734759 Index Cond: (unique1 < 100)
760+ Planning time: 0.079 ms
735761 Total runtime: 14.727 ms
736762
737763ROLLBACK;
@@ -817,6 +843,7 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000
817843 Index Cond: (unique2 > 9000)
818844 Filter: (unique1 < 100)
819845 Rows Removed by Filter: 287
846+ Planning time: 0.096 ms
820847 Total runtime: 0.336 ms
821848</screen>
822849
0 commit comments