involve any subset of the index's columns. Unlike B-tree or GiST,
   index search effectiveness is the same regardless of which index column(s)
   the query conditions use.
  </para>

  <para>
   A multicolumn BRIN index can be used with query conditions that
   involve any subset of the index's columns. Like GIN and unlike B-tree or
   GiST, index search effectiveness is the same regardless of which index
   column(s) the query conditions use. The only reason to have multiple BRIN
   indexes instead of one multicolumn BRIN index on a single table is to have
   a different <literal>pages_per_range</literal> storage parameter.
  </para>

  <para>
   Of course, each column must be used with operators appropriate to the index
   type; clauses that involve other operators will not be considered.
  </para>

  <para>
   Multicolumn indexes should be used sparingly.  In most situations,
   an index on a single column is sufficient and saves space and time.
   Indexes with more than three columns are unlikely to be helpful
   unless the usage of the table is extremely stylized.  See also
   <xref linkend="indexes-bitmap-scans"/> and
   <xref linkend="indexes-index-only-scans"/> for some discussion of the
   merits of different index configurations.
  </para>
 </sect1>


 <sect1 id="indexes-ordering">
  <title>Indexes and <literal>ORDER BY</literal></title>

  <indexterm zone="indexes-ordering">
   <primary>index</primary>
   <secondary>and <literal>ORDER BY</literal></secondary>
  </indexterm>

  <para>
   In addition to simply finding the rows to be returned by a query,
   an index may be able to deliver them in a specific sorted order.
   This allows a query's <literal>ORDER BY</literal> specification to be honored
   without a separate sorting step.  Of the index types currently
   supported by <productname>PostgreSQL</productname>, only B-tree
   can produce sorted output &mdash; the other index types return
   matching rows in an unspecified, implementation-dependent order.
  </para>

  <para>
   The planner will consider satisfying an <literal>ORDER BY</literal> specification
   either by scanning an available index that matches the specification,
   or by scanning the table in physical order and doing an explicit
   sort.  For a query that requires scanning a large fraction of the
   table, an explicit sort is likely to be faster than using an index
   because it requires
   less disk I/O due to following a sequential access pattern.  Indexes are
   more useful when only a few rows need be fetched.  An important
   special case is <literal>ORDER BY</literal> in combination with
   <literal>LIMIT</literal> <replaceable>n</replaceable>: an explicit sort will have to process
   all the data to identify the first <replaceable>n</replaceable> rows, but if there is
   an index matching the <literal>ORDER BY</literal>, the first <replaceable>n</replaceable>
   rows can be retrieved directly, without scanning the remainder at all.
  </para>

  <para>
   By default, B-tree indexes store their entries in ascending order
   with nulls last (table TID is treated as a tiebreaker column among
   otherwise equal entries).  This means that a forward scan of an
   index on column <literal>x</literal> produces output satisfying <literal>ORDER BY x</literal>
   (or more verbosely, <literal>ORDER BY x ASC NULLS LAST</literal>).  The
   index can also be scanned backward, producing output satisfying
   <literal>ORDER BY x DESC</literal>
   (or more verbosely, <literal>ORDER BY x DESC NULLS FIRST</literal>, since
   <literal>NULLS FIRST</literal> is the default for <literal>ORDER BY DESC</literal>).
  </para>

  <para>
   You can adjust the ordering of a B-tree index by including the
   options <literal>ASC</literal>, <literal>DESC</literal>, <literal>NULLS FIRST</literal>,
   and/or <literal>NULLS LAST</literal> when creating the index; for example:
<programlisting>
CREATE INDEX test2_info_nulls_low ON test2 (info NULLS FIRST);
CREATE INDEX test3_desc_index