pgstat: Update docs to match the shared memory stats reality.
This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
This commit is contained in:
parent
76cbf7edb6
commit
b3abca6810
|
@ -1036,8 +1036,6 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
|
||||||
<filename>pg_snapshots/</filename>, <filename>pg_stat_tmp/</filename>,
|
<filename>pg_snapshots/</filename>, <filename>pg_stat_tmp/</filename>,
|
||||||
and <filename>pg_subtrans/</filename> (but not the directories themselves) can be
|
and <filename>pg_subtrans/</filename> (but not the directories themselves) can be
|
||||||
omitted from the backup as they will be initialized on postmaster startup.
|
omitted from the backup as they will be initialized on postmaster startup.
|
||||||
If <xref linkend="guc-stats-temp-directory"/> is set and is under the data
|
|
||||||
directory then the contents of that directory can also be omitted.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -9593,9 +9593,9 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
|
||||||
<para>
|
<para>
|
||||||
<xref linkend="view-table"/> lists the system views described here.
|
<xref linkend="view-table"/> lists the system views described here.
|
||||||
More detailed documentation of each view follows below.
|
More detailed documentation of each view follows below.
|
||||||
There are some additional views that provide access to the results of
|
There are some additional views that provide access to accumulated
|
||||||
the statistics collector; they are described in <xref
|
statistics; they are described in
|
||||||
linkend="monitoring-stats-views-table"/>.
|
<xref linkend="monitoring-stats-views-table"/>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -7885,15 +7885,15 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
|
||||||
<sect1 id="runtime-config-statistics">
|
<sect1 id="runtime-config-statistics">
|
||||||
<title>Run-time Statistics</title>
|
<title>Run-time Statistics</title>
|
||||||
|
|
||||||
<sect2 id="runtime-config-statistics-collector">
|
<sect2 id="runtime-config-cumulative-statistics">
|
||||||
<title>Query and Index Statistics Collector</title>
|
<title>Cumulative Query and Index Statistics</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These parameters control server-wide statistics collection features.
|
These parameters control the server-wide cumulative statistics system.
|
||||||
When statistics collection is enabled, the data that is produced can be
|
When enabled, the data that is collected can be accessed via the
|
||||||
accessed via the <structname>pg_stat</structname> and
|
<structname>pg_stat</structname> and <structname>pg_statio</structname>
|
||||||
<structname>pg_statio</structname> family of system views.
|
family of system views. Refer to <xref linkend="monitoring"/> for more
|
||||||
Refer to <xref linkend="monitoring"/> for more information.
|
information.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
|
@ -8031,22 +8031,37 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry id="guc-stats-temp-directory" xreflabel="stats_temp_directory">
|
<varlistentry id="guc-stats-fetch-consistency" xreflabel="stats_fetch_consistency">
|
||||||
<term><varname>stats_temp_directory</varname> (<type>string</type>)
|
<term><varname>stats_fetch_consistency</varname> (<type>enum</type>)
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary><varname>stats_temp_directory</varname> configuration parameter</primary>
|
<primary><varname>stats_fetch_consistency</varname> configuration parameter</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Sets the directory to store temporary statistics data in. This can be
|
Determines the behavior when cumulative statistics are accessed
|
||||||
a path relative to the data directory or an absolute path. The default
|
multiple times within a transaction. When set to
|
||||||
is <filename>pg_stat_tmp</filename>. Pointing this at a RAM-based
|
<literal>none</literal>, each access re-fetches counters from shared
|
||||||
file system will decrease physical I/O requirements and can lead to
|
memory. When set to <literal>cache</literal>, the first access to
|
||||||
improved performance.
|
statistics for an object caches those statistics until the end of the
|
||||||
This parameter can only be set in the <filename>postgresql.conf</filename>
|
transaction unless <function>pg_stat_clear_snapshot()</function> is
|
||||||
file or on the server command line.
|
called. When set to <literal>snapshot</literal>, the first statistics
|
||||||
|
access caches all statistics accessible in the current database, until
|
||||||
|
the end of the transaction unless
|
||||||
|
<function>pg_stat_clear_snapshot()</function> is called. The default
|
||||||
|
is <literal>cache</literal>.
|
||||||
</para>
|
</para>
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
<literal>none</literal> is most suitable for monitoring systems. If
|
||||||
|
values are only accessed once, it is the most
|
||||||
|
efficient. <literal>cache</literal> ensures repeat accesses yield the
|
||||||
|
same values, which is important for queries involving
|
||||||
|
e.g. self-joins. <literal>snapshot</literal> can be useful when
|
||||||
|
interactively inspecting statistics, but has higher overhead,
|
||||||
|
particularly if many database objects exist.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
|
|
@ -28019,8 +28019,8 @@ SELECT collation for ('foo' COLLATE "de_DE");
|
||||||
<para>
|
<para>
|
||||||
Requests to log the memory contexts of the backend with the
|
Requests to log the memory contexts of the backend with the
|
||||||
specified process ID. This function can send the request to
|
specified process ID. This function can send the request to
|
||||||
backends and auxiliary processes except logger and statistics
|
backends and auxiliary processes except logger. These memory contexts
|
||||||
collector. These memory contexts will be logged at
|
will be logged at
|
||||||
<literal>LOG</literal> message level. They will appear in
|
<literal>LOG</literal> message level. They will appear in
|
||||||
the server log based on the log configuration set
|
the server log based on the log configuration set
|
||||||
(See <xref linkend="runtime-config-logging"/> for more information),
|
(See <xref linkend="runtime-config-logging"/> for more information),
|
||||||
|
|
|
@ -136,9 +136,9 @@
|
||||||
The auxiliary processes consist of <!-- in alphabetical order -->
|
The auxiliary processes consist of <!-- in alphabetical order -->
|
||||||
<!-- NB: In the code, the autovac launcher doesn't use the auxiliary
|
<!-- NB: In the code, the autovac launcher doesn't use the auxiliary
|
||||||
process scaffolding; however it does behave as one so we list it
|
process scaffolding; however it does behave as one so we list it
|
||||||
here anyway. In addition, logger and stats collector aren't
|
here anyway. In addition, logger isn't connected to shared memory so
|
||||||
connected to shared memory so most code outside postmaster.c
|
most code outside postmaster.c doesn't even consider them "procs" in
|
||||||
doesn't even consider them "procs" in the first place.
|
the first place.
|
||||||
-->
|
-->
|
||||||
the <glossterm linkend="glossary-autovacuum">autovacuum launcher</glossterm>
|
the <glossterm linkend="glossary-autovacuum">autovacuum launcher</glossterm>
|
||||||
(but not the autovacuum workers),
|
(but not the autovacuum workers),
|
||||||
|
@ -146,7 +146,6 @@
|
||||||
the <glossterm linkend="glossary-checkpointer">checkpointer</glossterm>,
|
the <glossterm linkend="glossary-checkpointer">checkpointer</glossterm>,
|
||||||
the <glossterm linkend="glossary-logger">logger</glossterm>,
|
the <glossterm linkend="glossary-logger">logger</glossterm>,
|
||||||
the <glossterm linkend="glossary-startup-process">startup process</glossterm>,
|
the <glossterm linkend="glossary-startup-process">startup process</glossterm>,
|
||||||
the <glossterm linkend="glossary-stats-collector">statistics collector</glossterm>,
|
|
||||||
the <glossterm linkend="glossary-wal-archiver">WAL archiver</glossterm>,
|
the <glossterm linkend="glossary-wal-archiver">WAL archiver</glossterm>,
|
||||||
the <glossterm linkend="glossary-wal-receiver">WAL receiver</glossterm>
|
the <glossterm linkend="glossary-wal-receiver">WAL receiver</glossterm>
|
||||||
(but not the <glossterm linkend="glossary-wal-sender">WAL senders</glossterm>),
|
(but not the <glossterm linkend="glossary-wal-sender">WAL senders</glossterm>),
|
||||||
|
@ -434,6 +433,21 @@
|
||||||
</glossdef>
|
</glossdef>
|
||||||
</glossentry>
|
</glossentry>
|
||||||
|
|
||||||
|
<glossentry id="glossary-cumulative-statistics">
|
||||||
|
<glossterm>Cumulative Statistics System</glossterm>
|
||||||
|
<glossdef>
|
||||||
|
<para>
|
||||||
|
A system which, if enabled, accumulates statistical information
|
||||||
|
about the <glossterm linkend="glossary-instance">instance</glossterm>'s
|
||||||
|
activities.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
For more information, see
|
||||||
|
<xref linkend="monitoring-stats"/>.
|
||||||
|
</para>
|
||||||
|
</glossdef>
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
<glossentry>
|
<glossentry>
|
||||||
<glossterm>Data area</glossterm>
|
<glossterm>Data area</glossterm>
|
||||||
<glosssee otherterm="glossary-data-directory" />
|
<glosssee otherterm="glossary-data-directory" />
|
||||||
|
@ -1563,22 +1577,6 @@
|
||||||
</glossdef>
|
</glossdef>
|
||||||
</glossentry>
|
</glossentry>
|
||||||
|
|
||||||
<glossentry id="glossary-stats-collector">
|
|
||||||
<glossterm>Stats collector (process)</glossterm>
|
|
||||||
<glossdef>
|
|
||||||
<para>
|
|
||||||
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
||||||
which, if enabled, receives statistical information
|
|
||||||
about the <glossterm linkend="glossary-instance">instance</glossterm>'s
|
|
||||||
activities.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
For more information, see
|
|
||||||
<xref linkend="monitoring-stats"/>.
|
|
||||||
</para>
|
|
||||||
</glossdef>
|
|
||||||
</glossentry>
|
|
||||||
|
|
||||||
<glossentry id="glossary-system-catalog">
|
<glossentry id="glossary-system-catalog">
|
||||||
<glossterm>System catalog</glossterm>
|
<glossterm>System catalog</glossterm>
|
||||||
<glossdef>
|
<glossdef>
|
||||||
|
|
|
@ -2227,12 +2227,13 @@ HINT: You can then restart the server after making the necessary configuration
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The statistics collector is active during recovery. All scans, reads, blocks,
|
The cumulative statistics system is active during recovery. All scans,
|
||||||
index usage, etc., will be recorded normally on the standby. Replayed
|
reads, blocks, index usage, etc., will be recorded normally on the
|
||||||
actions will not duplicate their effects on primary, so replaying an
|
standby. However, WAL replay will not increment relation and database
|
||||||
insert will not increment the Inserts column of pg_stat_user_tables.
|
specific counters. I.e. replay will not increment pg_stat_all_tables
|
||||||
The stats file is deleted at the start of recovery, so stats from primary
|
columns (like n_tup_ins), nor will reads or writes performed by the
|
||||||
and standby will differ; this is considered a feature, not a bug.
|
startup process be tracked in the pg_statio views, nor will associated
|
||||||
|
pg_stat_database columns be incremented.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -839,7 +839,7 @@ vacuum insert threshold = vacuum base insert threshold + vacuum insert scale fac
|
||||||
it may be beneficial to lower the table's
|
it may be beneficial to lower the table's
|
||||||
<xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow
|
<xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow
|
||||||
tuples to be frozen by earlier vacuums. The number of obsolete tuples and
|
tuples to be frozen by earlier vacuums. The number of obsolete tuples and
|
||||||
the number of inserted tuples are obtained from the statistics collector;
|
the number of inserted tuples are obtained from the cumulative statistics system;
|
||||||
it is a semi-accurate count updated by each <command>UPDATE</command>,
|
it is a semi-accurate count updated by each <command>UPDATE</command>,
|
||||||
<command>DELETE</command> and <command>INSERT</command> operation. (It is
|
<command>DELETE</command> and <command>INSERT</command> operation. (It is
|
||||||
only semi-accurate because some information might be lost under heavy
|
only semi-accurate because some information might be lost under heavy
|
||||||
|
|
|
@ -22,7 +22,7 @@
|
||||||
<para>
|
<para>
|
||||||
Several tools are available for monitoring database activity and
|
Several tools are available for monitoring database activity and
|
||||||
analyzing performance. Most of this chapter is devoted to describing
|
analyzing performance. Most of this chapter is devoted to describing
|
||||||
<productname>PostgreSQL</productname>'s statistics collector,
|
<productname>PostgreSQL</productname>'s cumulative statistics system,
|
||||||
but one should not neglect regular Unix monitoring programs such as
|
but one should not neglect regular Unix monitoring programs such as
|
||||||
<command>ps</command>, <command>top</command>, <command>iostat</command>, and <command>vmstat</command>.
|
<command>ps</command>, <command>top</command>, <command>iostat</command>, and <command>vmstat</command>.
|
||||||
Also, once one has identified a
|
Also, once one has identified a
|
||||||
|
@ -53,7 +53,6 @@ postgres 15554 0.0 0.0 57536 1184 ? Ss 18:02 0:00 postgres: back
|
||||||
postgres 15555 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: checkpointer
|
postgres 15555 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: checkpointer
|
||||||
postgres 15556 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: walwriter
|
postgres 15556 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: walwriter
|
||||||
postgres 15557 0.0 0.0 58504 2244 ? Ss 18:02 0:00 postgres: autovacuum launcher
|
postgres 15557 0.0 0.0 58504 2244 ? Ss 18:02 0:00 postgres: autovacuum launcher
|
||||||
postgres 15558 0.0 0.0 17512 1068 ? Ss 18:02 0:00 postgres: stats collector
|
|
||||||
postgres 15582 0.0 0.0 58772 3080 ? Ss 18:04 0:00 postgres: joe runbug 127.0.0.1 idle
|
postgres 15582 0.0 0.0 58772 3080 ? Ss 18:04 0:00 postgres: joe runbug 127.0.0.1 idle
|
||||||
postgres 15606 0.0 0.0 58772 3052 ? Ss 18:07 0:00 postgres: tgl regression [local] SELECT waiting
|
postgres 15606 0.0 0.0 58772 3052 ? Ss 18:07 0:00 postgres: tgl regression [local] SELECT waiting
|
||||||
postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl regression [local] idle in transaction
|
postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl regression [local] idle in transaction
|
||||||
|
@ -63,11 +62,10 @@ postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl
|
||||||
platforms, as do the details of what is shown. This example is from a
|
platforms, as do the details of what is shown. This example is from a
|
||||||
recent Linux system.) The first process listed here is the
|
recent Linux system.) The first process listed here is the
|
||||||
primary server process. The command arguments
|
primary server process. The command arguments
|
||||||
shown for it are the same ones used when it was launched. The next five
|
shown for it are the same ones used when it was launched. The next four
|
||||||
processes are background worker processes automatically launched by the
|
processes are background worker processes automatically launched by the
|
||||||
primary process. (The <quote>stats collector</quote> process will not be present
|
primary process. (The <quote>autovacuum launcher</quote> process will not
|
||||||
if you have set the system not to start the statistics collector; likewise
|
be present if you have set the system not to run autovacuum.)
|
||||||
the <quote>autovacuum launcher</quote> process can be disabled.)
|
|
||||||
Each of the remaining
|
Each of the remaining
|
||||||
processes is a server process handling one client connection. Each such
|
processes is a server process handling one client connection. Each such
|
||||||
process sets its command line display in the form
|
process sets its command line display in the form
|
||||||
|
@ -130,20 +128,20 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="monitoring-stats">
|
<sect1 id="monitoring-stats">
|
||||||
<title>The Statistics Collector</title>
|
<title>The Cumulative Statistics System</title>
|
||||||
|
|
||||||
<indexterm zone="monitoring-stats">
|
<indexterm zone="monitoring-stats">
|
||||||
<primary>statistics</primary>
|
<primary>statistics</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname>'s <firstterm>statistics collector</firstterm>
|
<productname>PostgreSQL</productname>'s <firstterm>cumulative statistics
|
||||||
is a subsystem that supports collection and reporting of information about
|
system</firstterm> supports collection and reporting of information about
|
||||||
server activity. Presently, the collector can count accesses to tables
|
server activity. Presently, accesses to tables and indexes in both
|
||||||
and indexes in both disk-block and individual-row terms. It also tracks
|
disk-block and individual-row terms are counted. The total number of rows
|
||||||
the total number of rows in each table, and information about vacuum and
|
in each table, and information about vacuum and analyze actions for each
|
||||||
analyze actions for each table. It can also count calls to user-defined
|
table are also counted. If enabled, calls to user-defined functions and
|
||||||
functions and the total time spent in each one.
|
the total time spent in each one are counted as well.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -151,7 +149,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
information about exactly what is going on in the system right now, such as
|
information about exactly what is going on in the system right now, such as
|
||||||
the exact command currently being executed by other server processes, and
|
the exact command currently being executed by other server processes, and
|
||||||
which other connections exist in the system. This facility is independent
|
which other connections exist in the system. This facility is independent
|
||||||
of the collector process.
|
of the cumulative statistics system.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect2 id="monitoring-stats-setup">
|
<sect2 id="monitoring-stats-setup">
|
||||||
|
@ -172,7 +170,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The parameter <xref linkend="guc-track-counts"/> controls whether
|
The parameter <xref linkend="guc-track-counts"/> controls whether
|
||||||
statistics are collected about table and index accesses.
|
cumulative statistics are collected about table and index accesses.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -201,18 +199,15 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The statistics collector transmits the collected information to other
|
Cumulative statistics are collected in shared memory. Every
|
||||||
<productname>PostgreSQL</productname> processes through temporary files.
|
<productname>PostgreSQL</productname> process collects statistics locally
|
||||||
These files are stored in the directory named by the
|
then updates the shared data at appropriate intervals. When a server,
|
||||||
<xref linkend="guc-stats-temp-directory"/> parameter,
|
including a physical replica, shuts down cleanly, a permanent copy of the
|
||||||
<filename>pg_stat_tmp</filename> by default.
|
statistics data is stored in the <filename>pg_stat</filename> subdirectory,
|
||||||
For better performance, <varname>stats_temp_directory</varname> can be
|
so that statistics can be retained across server restarts. In contrast,
|
||||||
pointed at a RAM-based file system, decreasing physical I/O requirements.
|
when starting from an unclean shutdown (e.g., after an immediate shutdown,
|
||||||
When the server shuts down cleanly, a permanent copy of the statistics
|
a server crash, starting from a base backup, and point-in-time recovery),
|
||||||
data is stored in the <filename>pg_stat</filename> subdirectory, so that
|
all statistics counters are reset.
|
||||||
statistics can be retained across server restarts. When recovery is
|
|
||||||
performed at server start (e.g., after immediate shutdown, server crash,
|
|
||||||
and point-in-time recovery), all statistics counters are reset.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
@ -225,48 +220,58 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
linkend="monitoring-stats-dynamic-views-table"/>, are available to show
|
linkend="monitoring-stats-dynamic-views-table"/>, are available to show
|
||||||
the current state of the system. There are also several other
|
the current state of the system. There are also several other
|
||||||
views, listed in <xref
|
views, listed in <xref
|
||||||
linkend="monitoring-stats-views-table"/>, available to show the results
|
linkend="monitoring-stats-views-table"/>, available to show the accumulated
|
||||||
of statistics collection. Alternatively, one can
|
statistics. Alternatively, one can
|
||||||
build custom views using the underlying statistics functions, as discussed
|
build custom views using the underlying cumulative statistics functions, as
|
||||||
in <xref linkend="monitoring-stats-functions"/>.
|
discussed in <xref linkend="monitoring-stats-functions"/>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When using the statistics to monitor collected data, it is important
|
When using the cumulative statistics views and functions to monitor
|
||||||
to realize that the information does not update instantaneously.
|
collected data, it is important to realize that the information does not
|
||||||
Each individual server process transmits new statistical counts to
|
update instantaneously. Each individual server process flushes out
|
||||||
the collector just before going idle; so a query or transaction still in
|
accumulated statistics to shared memory just before going idle, but not
|
||||||
progress does not affect the displayed totals. Also, the collector itself
|
more frequently than once per <varname>PGSTAT_MIN_INTERVAL</varname>
|
||||||
emits a new report at most once per <varname>PGSTAT_STAT_INTERVAL</varname>
|
milliseconds (1 second unless altered while building the server); so a
|
||||||
milliseconds (500 ms unless altered while building the server). So the
|
query or transaction still in progress does not affect the displayed totals
|
||||||
displayed information lags behind actual activity. However, current-query
|
and the displayed information lags behind actual activity. However,
|
||||||
information collected by <varname>track_activities</varname> is
|
current-query information collected by <varname>track_activities</varname>
|
||||||
always up-to-date.
|
is always up-to-date.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Another important point is that when a server process is asked to display
|
Another important point is that when a server process is asked to display
|
||||||
any of these statistics, it first fetches the most recent report emitted by
|
any of the accumulated statistics, accessed values are cached until the end
|
||||||
the collector process and then continues to use this snapshot for all
|
of its current transaction in the default configuration. So the statistics
|
||||||
statistical views and functions until the end of its current transaction.
|
will show static information as long as you continue the current
|
||||||
So the statistics will show static information as long as you continue the
|
transaction. Similarly, information about the current queries of all
|
||||||
current transaction. Similarly, information about the current queries of
|
sessions is collected when any such information is first requested within a
|
||||||
all sessions is collected when any such information is first requested
|
transaction, and the same information will be displayed throughout the
|
||||||
within a transaction, and the same information will be displayed throughout
|
transaction. This is a feature, not a bug, because it allows you to perform
|
||||||
the transaction.
|
several queries on the statistics and correlate the results without
|
||||||
This is a feature, not a bug, because it allows you to perform several
|
worrying that the numbers are changing underneath you.
|
||||||
queries on the statistics and correlate the results without worrying that
|
|
||||||
the numbers are changing underneath you. But if you want to see new
|
When analyzing statistics interactively, or with expensive queries, the
|
||||||
results with each query, be sure to do the queries outside any transaction
|
time delta between accesses to individual statistics can lead to
|
||||||
block. Alternatively, you can invoke
|
significant skew in the cached statistics. To minimize skew,
|
||||||
<function>pg_stat_clear_snapshot</function>(), which will discard the
|
<varname>stats_fetch_consistency</varname> can be set to
|
||||||
current transaction's statistics snapshot (if any). The next use of
|
<literal>snapshot</literal>, at the price of increased memory usage for
|
||||||
statistical information will cause a new snapshot to be fetched.
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
A transaction can also see its own statistics (as yet untransmitted to the
|
A transaction can also see its own statistics (not yet flushed out to the
|
||||||
collector) in the views <structname>pg_stat_xact_all_tables</structname>,
|
shared memory statistics) in the views
|
||||||
|
<structname>pg_stat_xact_all_tables</structname>,
|
||||||
<structname>pg_stat_xact_sys_tables</structname>,
|
<structname>pg_stat_xact_sys_tables</structname>,
|
||||||
<structname>pg_stat_xact_user_tables</structname>, and
|
<structname>pg_stat_xact_user_tables</structname>, and
|
||||||
<structname>pg_stat_xact_user_functions</structname>. These numbers do not act as
|
<structname>pg_stat_xact_user_functions</structname>. These numbers do not act as
|
||||||
|
@ -663,7 +668,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||||
kernel's I/O cache, and might therefore still be fetched without
|
kernel's I/O cache, and might therefore still be fetched without
|
||||||
requiring a physical read. Users interested in obtaining more
|
requiring a physical read. Users interested in obtaining more
|
||||||
detailed information on <productname>PostgreSQL</productname> I/O behavior are
|
detailed information on <productname>PostgreSQL</productname> I/O behavior are
|
||||||
advised to use the <productname>PostgreSQL</productname> statistics collector
|
advised to use the <productname>PostgreSQL</productname> statistics views
|
||||||
in combination with operating system utilities that allow insight
|
in combination with operating system utilities that allow insight
|
||||||
into the kernel's handling of I/O.
|
into the kernel's handling of I/O.
|
||||||
</para>
|
</para>
|
||||||
|
@ -5171,8 +5176,8 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Additional functions related to statistics collection are listed in <xref
|
Additional functions related to the cumulative statistics system are listed
|
||||||
linkend="monitoring-stats-funcs-table"/>.
|
in <xref linkend="monitoring-stats-funcs-table"/>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table id="monitoring-stats-funcs-table">
|
<table id="monitoring-stats-funcs-table">
|
||||||
|
@ -5228,7 +5233,10 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Returns the timestamp of the current statistics snapshot, or NULL if
|
Returns the timestamp of the current statistics snapshot, or NULL if
|
||||||
no statistics snapshot has been taken.
|
no statistics snapshot has been taken. A snapshot is taken the first
|
||||||
|
time cumulative statistics are accessed in a transaction if
|
||||||
|
<varname>stats_fetch_consistency</varname> is set to
|
||||||
|
<literal>snapshot</literal>
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
|
@ -5241,7 +5249,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||||
<returnvalue>void</returnvalue>
|
<returnvalue>void</returnvalue>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Discards the current statistics snapshot.
|
Discards the current statistics snapshot or cached information.
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
|
@ -6405,8 +6413,8 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
||||||
<entry>
|
<entry>
|
||||||
<command>VACUUM</command> is performing final cleanup. During this phase,
|
<command>VACUUM</command> is performing final cleanup. During this phase,
|
||||||
<command>VACUUM</command> will vacuum the free space map, update statistics
|
<command>VACUUM</command> will vacuum the free space map, update statistics
|
||||||
in <literal>pg_class</literal>, and report statistics to the statistics
|
in <literal>pg_class</literal>, and report statistics to the cumulative
|
||||||
collector. When this phase is completed, <command>VACUUM</command> will end.
|
statistics system. When this phase is completed, <command>VACUUM</command> will end.
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
|
@ -1329,7 +1329,7 @@ PostgreSQL documentation
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The database activity of <application>pg_dump</application> is
|
The database activity of <application>pg_dump</application> is
|
||||||
normally collected by the statistics collector. If this is
|
normally collected by the cumulative statistics system. If this is
|
||||||
undesirable, you can set parameter <varname>track_counts</varname>
|
undesirable, you can set parameter <varname>track_counts</varname>
|
||||||
to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
|
to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
|
||||||
USER</literal> command.
|
USER</literal> command.
|
||||||
|
|
Loading…
Reference in New Issue