partition from the query
    plan.
   </para>

   <para>
    By using the EXPLAIN command and the <xref
    linkend="guc-enable-partition-pruning"/> configuration parameter, it's
    possible to show the difference between a plan for which partitions have
    been pruned and one for which they have not.  A typical unoptimized
    plan for this type of table setup is:
<programlisting>
SET enable_partition_pruning = off;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
                                    QUERY PLAN
-------------------------------------------------------------------&zwsp;----------------
 Aggregate  (cost=188.76..188.77 rows=1 width=8)
   -&gt;  Append  (cost=0.00..181.05 rows=3085 width=0)
         -&gt;  Seq Scan on measurement_y2006m02  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on measurement_y2006m03  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate &gt;= '2008-01-01'::date)
...
         -&gt;  Seq Scan on measurement_y2007m11  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on measurement_y2007m12  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on measurement_y2008m01  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate &gt;= '2008-01-01'::date)
</programlisting>

    Some or all of the partitions might use index scans instead of
    full-table sequential scans, but the point here is that there
    is no need to scan the older partitions at all to answer this query.
    When we enable partition pruning, we get a significantly
    cheaper plan that will deliver the same answer:
<programlisting>
SET enable_partition_pruning = on;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
                                    QUERY PLAN
-------------------------------------------------------------------&zwsp;----------------
 Aggregate  (cost=37.75..37.76 rows=1 width=8)
   -&gt;  Seq Scan on measurement_y2008m01  (cost=0.00..33.12 rows=617 width=0)
         Filter: (logdate &gt;= '2008-01-01'::date)
</programlisting>
   </para>

   <para>
    Note that partition pruning is driven only by the constraints defined
    implicitly by the partition keys, not by the presence of indexes.
    Therefore it isn't necessary to define indexes on the key columns.
    Whether an index needs to be created for a given partition depends on
    whether you expect that queries that scan the partition will
    generally scan a large part of the partition or just a small part.
    An index will be helpful in the latter case but not the former.
   </para>

   <para>
    Partition pruning can be performed not only during the planning of a
    given query, but also during its execution.  This is useful as it can
    allow more partitions to be pruned when clauses contain expressions
    whose values are not known at query planning time, for example,
    parameters defined in a <command>PREPARE</command> statement, using a
    value obtained from a subquery, or using a parameterized value on the
    inner side of a nested loop join.  Partition pruning during execution
    can be performed at any of the following times:

    <itemizedlist>
     <listitem>
      <para>
       During initialization of the query plan.  Partition pruning can be
       performed here for parameter values which are known during the
       initialization phase of execution.  Partitions which are pruned
       during this stage will not show up in the query's
       <command>EXPLAIN</command> or <command>EXPLAIN ANALYZE</command>.
       It is possible to determine the number of partitions which were
       removed during this phase by observing the
       <quote>Subplans Removed</quote> property in the
       <command>EXPLAIN</command> output.  The query planner