combined via AND or OR rules,
   so it is difficult to associate individual heap row fetches
   with specific indexes when a bitmap scan is used.  Therefore, a bitmap
   scan increments the
   <structname>pg_stat_all_indexes</structname>.<structfield>idx_tup_read</structfield>
   count(s) for the index(es) it uses, and it increments the
   <structname>pg_stat_all_tables</structname>.<structfield>idx_tup_fetch</structfield>
   count for the table, but it does not affect
   <structname>pg_stat_all_indexes</structname>.<structfield>idx_tup_fetch</structfield>.
   The optimizer also accesses indexes to check for supplied constants
   whose values are outside the recorded range of the optimizer statistics
   because the optimizer statistics might be stale.
  </para>

  <note>
   <para>
    The <structfield>idx_tup_read</structfield> and <structfield>idx_tup_fetch</structfield> counts
    can be different even without any use of bitmap scans,
    because <structfield>idx_tup_read</structfield> counts
    index entries retrieved from the index while <structfield>idx_tup_fetch</structfield>
    counts live rows fetched from the table.  The latter will be less if any
    dead or not-yet-committed rows are fetched using the index, or if any
    heap fetches are avoided by means of an index-only scan.
   </para>
  </note>

  <note>
   <para>
    Index scans may sometimes perform multiple index searches per execution.
    Each index search increments <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>,
    so it's possible for the count of index scans to significantly exceed the
    total number of index scan executor node executions.
   </para>
   <para>
    This can happen with queries that use certain <acronym>SQL</acronym>
    constructs to search for rows matching any value out of a list or array of
    multiple scalar values (see <xref linkend="functions-comparisons"/>).  It
    can also happen to queries with a
    <literal><replaceable>column_name</replaceable> =
     <replaceable>value1</replaceable> OR
     <replaceable>column_name</replaceable> =
     <replaceable>value2</replaceable> ...</literal> construct, though only
    when the optimizer transforms the construct into an equivalent
    multi-valued array representation.  Similarly, when B-tree index scans use
    the skip scan optimization, an index search is performed each time the
    scan is repositioned to the next index leaf page that might have matching
    tuples (see <xref linkend="indexes-multicolumn"/>).
   </para>
  </note>
  <tip>
   <para>
    <command>EXPLAIN ANALYZE</command> outputs the total number of index
    searches performed by each index scan node.  See
    <xref linkend="using-explain-analyze"/> for an example demonstrating how
    this works.
   </para>
  </tip>

 </sect2>

 <sect2 id="monitoring-pg-statio-all-tables-view">
  <title><structname>pg_statio_all_tables</structname></title>

  <indexterm>
   <primary>pg_statio_all_tables</primary>
  </indexterm>

  <para>
   The <structname>pg_statio_all_tables</structname> view will contain
   one row for each table in the current database (including TOAST
   tables), showing statistics about I/O on that specific table. The
   <structname>pg_statio_user_tables</structname> and
   <structname>pg_statio_sys_tables</structname> views
   contain the same information,
   but filtered to only show user and system tables respectively.
  </para>

  <table id="pg-statio-all-tables-view" xreflabel="pg_statio_all_tables">
   <title><structname>pg_statio_all_tables</structname> View</title>
   <tgroup cols="1">
    <thead>
     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       Column Type
      </para>
      <para>
       Description
      </para></entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>relid</structfield> <type>oid</type>
      </para>
      <para>