codekingpro/portable-devtools

1<?xml version="1.0" encoding="UTF-8" standalone="no"?>2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>11.12. Examining Index Usage</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="indexes-collations.html" title="11.11. Indexes and Collations" /><link rel="next" href="textsearch.html" title="Chapter 12. Full Text Search" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">11.12. Examining Index Usage</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="indexes-collations.html" title="11.11. Indexes and Collations">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="indexes.html" title="Chapter 11. Indexes">Up</a></td><th width="60%" align="center">Chapter 11. Indexes</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="textsearch.html" title="Chapter 12. Full Text Search">Next</a></td></tr></table><hr /></div><div class="sect1" id="INDEXES-EXAMINE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">11.12. Examining Index Usage <a href="#INDEXES-EXAMINE" class="id_link">#</a></h2></div></div></div><a id="id-1.5.10.15.2" class="indexterm"></a><p>3   Although indexes in <span class="productname">PostgreSQL</span> do not need4   maintenance or tuning, it is still important to check5   which indexes are actually used by the real-life query workload.6   Examining index usage for an individual query is done with the7   <a class="xref" href="sql-explain.html" title="EXPLAIN"><span class="refentrytitle">EXPLAIN</span></a>8   command; its application for this purpose is9   illustrated in <a class="xref" href="using-explain.html" title="14.1. Using EXPLAIN">Section 14.1</a>.10   It is also possible to gather overall statistics about index usage11   in a running server, as described in <a class="xref" href="monitoring-stats.html" title="28.2. The Cumulative Statistics System">Section 28.2</a>.12  </p><p>13   It is difficult to formulate a general procedure for determining14   which indexes to create.  There are a number of typical cases that15   have been shown in the examples throughout the previous sections.16   A good deal of experimentation is often necessary.17   The rest of this section gives some tips for that:18  </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>19     Always run <a class="xref" href="sql-analyze.html" title="ANALYZE"><span class="refentrytitle">ANALYZE</span></a>20     first.  This command21     collects statistics about the distribution of the values in the22     table.  This information is required to estimate the number of rows23     returned by a query, which is needed by the planner to assign24     realistic costs to each possible query plan.  In absence of any25     real statistics, some default values are assumed, which are26     almost certain to be inaccurate.  Examining an application's27     index usage without having run <code class="command">ANALYZE</code> is28     therefore a lost cause.29     See <a class="xref" href="routine-vacuuming.html#VACUUM-FOR-STATISTICS" title="25.1.3. Updating Planner Statistics">Section 25.1.3</a>30     and <a class="xref" href="routine-vacuuming.html#AUTOVACUUM" title="25.1.6. The Autovacuum Daemon">Section 25.1.6</a> for more information.31    </p></li><li class="listitem"><p>32     Use real data for experimentation.  Using test data for setting33     up indexes will tell you what indexes you need for the test data,34     but that is all.35    </p><p>36     It is especially fatal to use very small test data sets.37     While selecting 1000 out of 100000 rows could be a candidate for38     an index, selecting 1 out of 100 rows will hardly be, because the39     100 rows probably fit within a single disk page, and there40     is no plan that can beat sequentially fetching 1 disk page.41    </p><p>42     Also be careful when making up test data, which is often43     unavoidable when the application is not yet in production.44     Values that are very similar, completely random, or inserted in45     sorted order will skew the statistics away from the distribution46     that real data would have.47    </p></li><li class="listitem"><p>48     When indexes are not used, it can be useful for testing to force49     their use.  There are run-time parameters that can turn off50     various plan types (see <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-ENABLE" title="20.7.1. Planner Method Configuration">Section 20.7.1</a>).51     For instance, turning off sequential scans52     (<code class="varname">enable_seqscan</code>) and nested-loop joins53     (<code class="varname">enable_nestloop</code>), which are the most basic plans,54     will force the system to use a different plan.  If the system55     still chooses a sequential scan or nested-loop join then there is56     probably a more fundamental reason why the index is not being57     used; for example, the query condition does not match the index.58     (What kind of query can use what kind of index is explained in59     the previous sections.)60    </p></li><li class="listitem"><p>61     If forcing index usage does use the index, then there are two62     possibilities: Either the system is right and using the index is63     indeed not appropriate, or the cost estimates of the query plans64     are not reflecting reality.  So you should time your query with65     and without indexes.  The <code class="command">EXPLAIN ANALYZE</code>66     command can be useful here.67    </p></li><li class="listitem"><p>68     If it turns out that the cost estimates are wrong, there are,69     again, two possibilities.  The total cost is computed from the70     per-row costs of each plan node times the selectivity estimate of71     the plan node.  The costs estimated for the plan nodes can be adjusted72     via run-time parameters (described in <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS" title="20.7.2. Planner Cost Constants">Section 20.7.2</a>).73     An inaccurate selectivity estimate is due to74     insufficient statistics.  It might be possible to improve this by75     tuning the statistics-gathering parameters (see76     <a class="xref" href="sql-altertable.html" title="ALTER TABLE"><span class="refentrytitle">ALTER TABLE</span></a>).77    </p><p>78     If you do not succeed in adjusting the costs to be more79     appropriate, then you might have to resort to forcing index usage80     explicitly.  You might also want to contact the81     <span class="productname">PostgreSQL</span> developers to examine the issue.82    </p></li></ul></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="indexes-collations.html" title="11.11. Indexes and Collations">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="indexes.html" title="Chapter 11. Indexes">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="textsearch.html" title="Chapter 12. Full Text Search">Next</a></td></tr><tr><td width="40%" align="left" valign="top">11.11. Indexes and Collations </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> Chapter 12. Full Text Search</td></tr></table></div></body></html>