partitions.
     </para>
    </listitem>
   </varlistentry>

  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   You must be the owner of a table to create a statistics object
   reading it.  Once created, however, the ownership of the statistics
   object is independent of the underlying table(s).
  </para>

  <para>
   Expression statistics are per-expression and are similar to creating an
   index on the expression, except that they avoid the overhead of index
   maintenance. Expression statistics are built automatically for each
   expression in the statistics object definition.
  </para>

  <para>
   Extended statistics are not currently used by the planner for selectivity
   estimations made for table joins.  This limitation will likely be removed
   in a future version of <productname>PostgreSQL</productname>.
  </para>
 </refsect1>

 <refsect1 id="sql-createstatistics-examples">
  <title>Examples</title>

  <para>
   Create table <structname>t1</structname> with two functionally dependent columns, i.e.,
   knowledge of a value in the first column is sufficient for determining the
   value in the other column. Then functional dependency statistics are built
   on those columns:

<programlisting>
CREATE TABLE t1 (
    a   int,
    b   int
);

INSERT INTO t1 SELECT i/100, i/500
                 FROM generate_series(1,1000000) s(i);

ANALYZE t1;

-- the number of matching rows will be drastically underestimated:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

CREATE STATISTICS s1 (dependencies) ON a, b FROM t1;

ANALYZE t1;

-- now the row count estimate is more accurate:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);
</programlisting>

   Without functional-dependency statistics, the planner would assume
   that the two <literal>WHERE</literal> conditions are independent, and would
   multiply their selectivities together to arrive at a much-too-small
   row count estimate.
   With such statistics, the planner recognizes that the <literal>WHERE</literal>
   conditions are redundant and does not underestimate the row count.
  </para>

  <para>
   Create table <structname>t2</structname> with two perfectly correlated columns
   (containing identical data), and an MCV list on those columns:

<programlisting>
CREATE TABLE t2 (
    a   int,
    b   int
);

INSERT INTO t2 SELECT mod(i,100), mod(i,100)
                 FROM generate_series(1,1000000) s(i);

CREATE STATISTICS s2 (mcv) ON a, b FROM t2;

ANALYZE t2;

-- valid combination (found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 1);

-- invalid combination (not found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);
</programlisting>

   The MCV list gives the planner more detailed information about the
   specific values that commonly appear in the table, as well as an upper
   bound on the selectivities of combinations of values that do not appear
   in the table, allowing it to generate better estimates in both cases.
  </para>

  <para>
   Create table <structname>t3</structname> with a single timestamp column,
   and run queries using expressions on that column.  Without extended
   statistics, the