@@ -40,6 +40,7 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac
40
40
VERBOSE [ <replaceable class="parameter">boolean</replaceable> ]
41
41
COSTS [ <replaceable class="parameter">boolean</replaceable> ]
42
42
SETTINGS [ <replaceable class="parameter">boolean</replaceable> ]
43
+ GENERIC_PLAN [ <replaceable class="parameter">boolean</replaceable> ]
43
44
BUFFERS [ <replaceable class="parameter">boolean</replaceable> ]
44
45
WAL [ <replaceable class="parameter">boolean</replaceable> ]
45
46
TIMING [ <replaceable class="parameter">boolean</replaceable> ]
@@ -168,6 +169,22 @@ ROLLBACK;
168
169
</listitem>
169
170
</varlistentry>
170
171
172
+ <varlistentry>
173
+ <term><literal>GENERIC_PLAN</literal></term>
174
+ <listitem>
175
+ <para>
176
+ Allow the statement to contain parameter placeholders like
177
+ <literal>$1</literal>, and generate a generic plan that does not
178
+ depend on the values of those parameters.
179
+ See <link linkend="sql-prepare"><command>PREPARE</command></link>
180
+ for details about generic plans and the types of statement that
181
+ support parameters.
182
+ This parameter cannot be used together with <literal>ANALYZE</literal>.
183
+ It defaults to <literal>FALSE</literal>.
184
+ </para>
185
+ </listitem>
186
+ </varlistentry>
187
+
171
188
<varlistentry>
172
189
<term><literal>BUFFERS</literal></term>
173
190
<listitem>
@@ -191,7 +208,7 @@ ROLLBACK;
191
208
query processing.
192
209
The number of blocks shown for an
193
210
upper-level node includes those used by all its child nodes. In text
194
- format, only non-zero values are printed.It defaults to
211
+ format, only non-zero values are printed.This parameter defaults to
195
212
<literal>FALSE</literal>.
196
213
</para>
197
214
</listitem>
@@ -445,14 +462,15 @@ PREPARE query(int, int) AS SELECT sum(bar) FROM test
445
462
EXPLAIN ANALYZE EXECUTE query(100, 200);
446
463
447
464
QUERY PLAN
448
- -------------------------------------------------------------------&zwsp;-----------------------------------------------------
449
- HashAggregate (cost=9.54..9.54 rows=1 width=8 ) (actual time=0.156 ..0.161 rows=11 loops=1)
465
+ -------------------------------------------------------------------&zwsp;------------------------------------------------------
466
+ HashAggregate (cost=10.77..10.87 rows=10 width=12 ) (actual time=0.043 ..0.044 rows=10 loops=1)
450
467
Group Key: foo
451
- -> Index Scan using test_pkey on test (cost=0.29..9.29 rows=50 width=8) (actual time=0.039..0.091 rows=99 loops=1)
452
- Index Cond: ((id > $1) AND (id < $2))
453
- Planning time: 0.197 ms
454
- Execution time: 0.225 ms
455
- (6 rows)
468
+ Batches: 1 Memory Usage: 24kB
469
+ -> Index Scan using test_pkey on test (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99 loops=1)
470
+ Index Cond: ((id > 100) AND (id < 200))
471
+ Planning Time: 0.244 ms
472
+ Execution Time: 0.073 ms
473
+ (7 rows)
456
474
</programlisting>
457
475
</para>
458
476
@@ -467,6 +485,42 @@ EXPLAIN ANALYZE EXECUTE query(100, 200);
467
485
<command>ANALYZE</command>, even if the actual distribution of data
468
486
in the table has not changed.
469
487
</para>
488
+
489
+ <para>
490
+ Notice that the previous example showed a <quote>custom</quote> plan
491
+ for the specific parameter values given in <command>EXECUTE</command>.
492
+ We might also wish to see the generic plan for a parameterized
493
+ query, which can be done with <literal>GENERIC_PLAN</literal>:
494
+
495
+ <programlisting>
496
+ EXPLAIN (GENERIC_PLAN)
497
+ SELECT sum(bar) FROM test
498
+ WHERE id > $1 AND id < $2
499
+ GROUP BY foo;
500
+
501
+ QUERY PLAN
502
+ -------------------------------------------------------------------&zwsp;------------
503
+ HashAggregate (cost=26.79..26.89 rows=10 width=12)
504
+ Group Key: foo
505
+ -> Index Scan using test_pkey on test (cost=0.29..24.29 rows=500 width=8)
506
+ Index Cond: ((id > $1) AND (id < $2))
507
+ (4 rows)
508
+ </programlisting>
509
+
510
+ In this case the parser correctly inferred that <literal>$1</literal>
511
+ and <literal>$2</literal> should have the same data type
512
+ as <literal>id</literal>, so the lack of parameter type information
513
+ from <command>PREPARE</command> was not a problem. In other cases
514
+ it might be necessary to explicitly specify types for the parameter
515
+ symbols, which can be done by casting them, for example:
516
+
517
+ <programlisting>
518
+ EXPLAIN (GENERIC_PLAN)
519
+ SELECT sum(bar) FROM test
520
+ WHERE id > $1::integer AND id < $2::integer
521
+ GROUP BY foo;
522
+ </programlisting>
523
+ </para>
470
524
</refsect1>
471
525
472
526
<refsect1>