optional
   <literal>ASC</literal> or <literal>DESC</literal> keyword to set the sort direction to
   ascending or descending.  <literal>ASC</literal> order is the default.
   Ascending order puts smaller values first, where
   <quote>smaller</quote> is defined in terms of the
   <literal>&lt;</literal> operator.  Similarly, descending order is
   determined with the <literal>&gt;</literal> operator.
    <footnote>
     <para>
      Actually, <productname>PostgreSQL</productname> uses the <firstterm>default B-tree
      operator class</firstterm> for the expression's data type to determine the sort
      ordering for <literal>ASC</literal> and <literal>DESC</literal>.  Conventionally,
      data types will be set up so that the <literal>&lt;</literal> and
      <literal>&gt;</literal> operators correspond to this sort ordering,
      but a user-defined data type's designer could choose to do something
      different.
     </para>
    </footnote>
  </para>

  <para>
   The <literal>NULLS FIRST</literal> and <literal>NULLS LAST</literal> options can be
   used to determine whether nulls appear before or after non-null values
   in the sort ordering.  By default, null values sort as if larger than any
   non-null value; that is, <literal>NULLS FIRST</literal> is the default for
   <literal>DESC</literal> order, and <literal>NULLS LAST</literal> otherwise.
  </para>

  <para>
   Note that the ordering options are considered independently for each
   sort column.  For example <literal>ORDER BY x, y DESC</literal> means
   <literal>ORDER BY x ASC, y DESC</literal>, which is not the same as
   <literal>ORDER BY x DESC, y DESC</literal>.
  </para>

  <para>
   A <replaceable>sort_expression</replaceable> can also be the column label or number
   of an output column, as in:
<programlisting>
SELECT a + b AS sum, c FROM table1 ORDER BY sum;
SELECT a, max(b) FROM table1 GROUP BY a ORDER BY 1;
</programlisting>
   both of which sort by the first output column.  Note that an output
   column name has to stand alone, that is, it cannot be used in an expression
   &mdash; for example, this is <emphasis>not</emphasis> correct:
<programlisting>
SELECT a + b AS sum, c FROM table1 ORDER BY sum + c;          -- wrong
</programlisting>
   This restriction is made to reduce ambiguity.  There is still
   ambiguity if an <literal>ORDER BY</literal> item is a simple name that
   could match either an output column name or a column from the table
   expression.  The output column is used in such cases.  This would
   only cause confusion if you use <literal>AS</literal> to rename an output
   column to match some other table column's name.
  </para>

  <para>
   <literal>ORDER BY</literal> can be applied to the result of a
   <literal>UNION</literal>, <literal>INTERSECT</literal>, or <literal>EXCEPT</literal>
   combination, but in this case it is only permitted to sort by
   output column names or numbers, not by expressions.
  </para>
 </sect1>


 <sect1 id="queries-limit">
  <title><literal>LIMIT</literal> and <literal>OFFSET</literal></title>

  <indexterm zone="queries-limit">
   <primary>LIMIT</primary>
  </indexterm>

  <indexterm zone="queries-limit">
   <primary>OFFSET</primary>
  </indexterm>

  <para>
   <literal>LIMIT</literal> and <literal>OFFSET</literal> allow you to retrieve just
   a portion of the rows that are generated by the rest of the query:
<synopsis>
SELECT <replaceable>select_list</replaceable>
    FROM <replaceable>table_expression</replaceable>
    <optional> ORDER BY ... </optional>
    <optional> LIMIT { <replaceable class="parameter">count</replaceable> | ALL } </optional>
    <optional> OFFSET <replaceable class="parameter">start</replaceable> </optional>
</synopsis>
  </para>

  <para>
   If a limit count is given, no more than that many rows will be
   returned (but possibly fewer, if the query itself yields fewer rows).
   <literal>LIMIT ALL</literal> is the same as omitting the <literal>LIMIT</literal>
   clause, as