Sophie: postgresql8.3-docs-8.3.6-2mdv2008.1 x86

postgresql8.3-docs-8.3.6-2mdv2008.1.x86_64.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Examining Index Usage</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.3.6 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Indexes"
HREF="indexes.html"><LINK
REL="PREVIOUS"
TITLE="Operator Classes and Operator Families"
HREF="indexes-opclass.html"><LINK
REL="NEXT"
TITLE="Full Text Search"
HREF="textsearch.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2009-02-03T04:34:16"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
>PostgreSQL 8.3.6 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexes-opclass.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexes.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 11. Indexes</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="indexes.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="textsearch.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="INDEXES-EXAMINE"
>11.10. Examining Index Usage</A
></H1
><A
NAME="AEN17890"
></A
><P
>   Although indexes in <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> do not need
   maintenance and tuning, it is still important to check
   which indexes are actually used by the real-life query workload.
   Examining index usage for an individual query is done with the
   <A
HREF="sql-explain.html"
><I
>EXPLAIN</I
></A
>
   command; its application for this purpose is
   illustrated in <A
HREF="using-explain.html"
>Section 14.1</A
>.
   It is also possible to gather overall statistics about index usage
   in a running server, as described in <A
HREF="monitoring-stats.html"
>Section 26.2</A
>.
  </P
><P
>   It is difficult to formulate a general procedure for determining
   which indexes to set up.  There are a number of typical cases that
   have been shown in the examples throughout the previous sections.
   A good deal of experimentation will be necessary in most cases.
   The rest of this section gives some tips for that.
  </P
><P
></P
><UL
><LI
><P
>     Always run <A
HREF="sql-analyze.html"
><I
>ANALYZE</I
></A
>
     first.  This command
     collects statistics about the distribution of the values in the
     table.  This information is required to guess the number of rows
     returned by a query, which is needed by the planner to assign
     realistic costs to each possible query plan.  In absence of any
     real statistics, some default values are assumed, which are
     almost certain to be inaccurate.  Examining an application's
     index usage without having run <TT
CLASS="COMMAND"
>ANALYZE</TT
> is
     therefore a lost cause.
    </P
></LI
><LI
><P
>     Use real data for experimentation.  Using test data for setting
     up indexes will tell you what indexes you need for the test data,
     but that is all.
    </P
><P
>     It is especially fatal to use very small test data sets.
     While selecting 1000 out of 100000 rows could be a candidate for
     an index, selecting 1 out of 100 rows will hardly be, because the
     100 rows will probably fit within a single disk page, and there
     is no plan that can beat sequentially fetching 1 disk page.
    </P
><P
>     Also be careful when making up test data, which is often
     unavoidable when the application is not in production use yet.
     Values that are very similar, completely random, or inserted in
     sorted order will skew the statistics away from the distribution
     that real data would have.
    </P
></LI
><LI
><P
>     When indexes are not used, it can be useful for testing to force
     their use.  There are run-time parameters that can turn off
     various plan types (see <A
HREF="runtime-config-query.html#RUNTIME-CONFIG-QUERY-ENABLE"
>Section 18.6.1</A
>).
     For instance, turning off sequential scans
     (<TT
CLASS="VARNAME"
>enable_seqscan</TT
>) and nested-loop joins
     (<TT
CLASS="VARNAME"
>enable_nestloop</TT
>), which are the most basic plans,
     will force the system to use a different plan.  If the system
     still chooses a sequential scan or nested-loop join then there is
     probably a more fundamental reason why the index is not
     used; for example, the query condition does not match the index.
     (What kind of query can use what kind of index is explained in
     the previous sections.)
    </P
></LI
><LI
><P
>     If forcing index usage does use the index, then there are two
     possibilities: Either the system is right and using the index is
     indeed not appropriate, or the cost estimates of the query plans
     are not reflecting reality.  So you should time your query with
     and without indexes.  The <TT
CLASS="COMMAND"
>EXPLAIN ANALYZE</TT
>
     command can be useful here.
    </P
></LI
><LI
><P
>     If it turns out that the cost estimates are wrong, there are,
     again, two possibilities.  The total cost is computed from the
     per-row costs of each plan node times the selectivity estimate of
     the plan node.  The costs estimated for the plan nodes can be adjusted
     via run-time parameters (described in <A
HREF="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS"
>Section 18.6.2</A
>).
     An inaccurate selectivity estimate is due to
     insufficient statistics.  It might be possible to improve this by
     tuning the statistics-gathering parameters (see
     <A
HREF="sql-altertable.html"
><I
>ALTER TABLE</I
></A
>).
    </P
><P
>     If you do not succeed in adjusting the costs to be more
     appropriate, then you might have to resort to forcing index usage
     explicitly.  You might also want to contact the
     <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> developers to examine the issue.
    </P
></LI
></UL
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexes-opclass.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="textsearch.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Operator Classes and Operator Families</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="indexes.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Full Text Search</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>