unclean shutdown (e.g., after an immediate shutdown,
   a server crash, starting from a base backup, and point-in-time recovery),
   all statistics counters are reset.
  </para>

 </sect2>

 <sect2 id="monitoring-stats-views">
  <title>Viewing Statistics</title>

  <para>
   Several predefined views, listed in <xref
   linkend="monitoring-stats-dynamic-views-table"/>, are available to show
   the current state of the system. There are also several other
   views, listed in <xref
   linkend="monitoring-stats-views-table"/>, available to show the accumulated
   statistics.  Alternatively, one can
   build custom views using the underlying cumulative statistics functions, as
   discussed in <xref linkend="monitoring-stats-functions"/>.
  </para>

  <para>
   When using the cumulative statistics views and functions to monitor
   collected data, it is important to realize that the information does not
   update instantaneously.  Each individual server process flushes out
   accumulated statistics to shared memory just before going idle, but not
   more frequently than once per <varname>PGSTAT_MIN_INTERVAL</varname>
   milliseconds (1 second unless altered while building the server); so a
   query or transaction still in progress does not affect the displayed totals
   and the displayed information lags behind actual activity.  However,
   current-query information collected by <varname>track_activities</varname>
   is always up-to-date.
  </para>

  <para>
   Another important point is that when a server process is asked to display
   any of the accumulated statistics, accessed values are cached until the end
   of its current transaction in the default configuration. So the statistics
   will show static information as long as you continue the current
   transaction. Similarly, information about the current queries of all
   sessions is collected when any such information is first requested within a
   transaction, and the same information will be displayed throughout the
   transaction. This is a feature, not a bug, because it allows you to perform
   several queries on the statistics and correlate the results without
   worrying that the numbers are changing underneath you.

   When analyzing statistics interactively, or with expensive queries, the
   time delta between accesses to individual statistics can lead to
   significant skew in the cached statistics. To minimize skew,
   <varname>stats_fetch_consistency</varname> can be set to
   <literal>snapshot</literal>, at the price of increased memory usage for
   caching not-needed statistics data.  Conversely, if it's known that
   statistics are only accessed once, caching accessed statistics is
   unnecessary and can be avoided by setting
   <varname>stats_fetch_consistency</varname> to <literal>none</literal>.

   You can invoke <function>pg_stat_clear_snapshot()</function> to discard the
   current transaction's statistics snapshot or cached values (if any).  The
   next use of statistical information will (when in snapshot mode) cause a
   new snapshot to be built or (when in cache mode) accessed statistics to be
   cached.
  </para>

  <para>
   A transaction can also see its own statistics (not yet flushed out to the
   shared memory statistics) in the views
   <structname>pg_stat_xact_all_tables</structname>,
   <structname>pg_stat_xact_sys_tables</structname>,
   <structname>pg_stat_xact_user_tables</structname>, and
   <structname>pg_stat_xact_user_functions</structname>.  These numbers do not act as
   stated above; instead they update continuously throughout the transaction.
  </para>

  <para>
   Some of the information in the dynamic statistics views shown in <xref
   linkend="monitoring-stats-dynamic-views-table"/> is security restricted.
   Ordinary users can only see all the information about their own sessions
   (sessions belonging to a role that they are a member of).  In rows about
   other sessions, many columns will be null.  Note, however, that the
   existence