read, but there are so few that the
    extra cost of sorting the row locations is not worth it.  You'll most
    often see this plan type for queries that fetch just a single row.  It's
    also often used for queries that have an <literal>ORDER BY</literal> condition
    that matches the index order, because then no extra sorting step is needed
    to satisfy the <literal>ORDER BY</literal>.  In this example, adding
    <literal>ORDER BY unique1</literal> would use the same plan because the
    index already implicitly provides the requested ordering.
   </para>

   <para>
     The planner may implement an <literal>ORDER BY</literal> clause in several
     ways.  The above example shows that such an ordering clause may be
     implemented implicitly.  The planner may also add an explicit
     <literal>Sort</literal> step:

<screen>
EXPLAIN SELECT * FROM tenk1 ORDER BY unique1;

                            QUERY PLAN
-------------------------------------------------------------------
 Sort  (cost=1109.39..1134.39 rows=10000 width=244)
   Sort Key: unique1
   ->  Seq Scan on tenk1  (cost=0.00..445.00 rows=10000 width=244)
</screen>

    If a part of the plan guarantees an ordering on a prefix of the
    required sort keys, then the planner may instead decide to use an
    <literal>Incremental Sort</literal> step:

<screen>
EXPLAIN SELECT * FROM tenk1 ORDER BY hundred, ten LIMIT 100;

                                              QUERY PLAN
-------------------------------------------------------------------&zwsp;-----------------------------
 Limit  (cost=19.35..39.49 rows=100 width=244)
   -&gt;  Incremental Sort  (cost=19.35..2033.39 rows=10000 width=244)
         Sort Key: hundred, ten
         Presorted Key: hundred
         -&gt;  Index Scan using tenk1_hundred on tenk1  (cost=0.29..1574.20 rows=10000 width=244)
</screen>

    Compared to regular sorts, sorting incrementally allows returning tuples
    before the entire result set has been sorted, which particularly enables
    optimizations with <literal>LIMIT</literal> queries.  It may also reduce
    memory usage and the likelihood of spilling sorts to disk, but it comes at
    the cost of the increased overhead of splitting the result set into multiple
    sorting batches.
   </para>

   <para>
    If there are separate indexes on several of the columns referenced
    in <literal>WHERE</literal>, the planner might choose to use an AND or OR
    combination of the indexes:

<screen>
EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 100 AND unique2 &gt; 9000;

                                     QUERY PLAN
-------------------------------------------------------------------&zwsp;------------------
 Bitmap Heap Scan on tenk1  (cost=25.07..60.11 rows=10 width=244)
   Recheck Cond: ((unique1 &lt; 100) AND (unique2 &gt; 9000))
   -&gt;  BitmapAnd  (cost=25.07..25.07 rows=10 width=0)
         -&gt;  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
               Index Cond: (unique1 &lt; 100)
         -&gt;  Bitmap Index Scan on tenk1_unique2  (cost=0.00..19.78 rows=999 width=0)
               Index Cond: (unique2 &gt; 9000)
</screen>

    But this requires visiting both indexes, so it's not necessarily a win
    compared to using just one index and treating the other condition as
    a filter.  If you vary the ranges involved you'll see the plan change
    accordingly.
   </para>

   <para>
    Here is an example showing the effects of <literal>LIMIT</literal>:

<screen>
EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 100 AND unique2 &gt; 9000 LIMIT 2;

                                     QUERY PLAN
-------------------------------------------------------------------&zwsp;------------------
 Limit  (cost=0.29..14.28 rows=2 width=244)
   -&gt;  Index Scan using tenk1_unique2 on tenk1  (cost=0.29..70.27 rows=10 width=244)
         Index Cond: (unique2 &gt; 9000)
         Filter: (unique1 &lt; 100)
</screen>
   </para>

   <para>
    This is the same query as