pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feeddescriptions of pg_stat_user_functions and pg_stat_slru
10+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2020-05-29 92f9468657 doc: Update the layout of "Viewing Statistics" section.
* descriptions of pg_stat_user_functions and pg_stat_slru
@ 2020-05-20 01:29 Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-20 01:29 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
Hi,
In monitoring.sgml, there are the tables and corresponding descriptions
for pg_stat_user_functions and pg_stat_slru views. I found that those
descriptions are located in opposite places. For example, the description
for pg_stat_user_functions wrongly comes just after the table for
pg_stat_slru view. Attached patch fixes this issue.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments:
monitoring_docfix.patch (text/plain, 1.8K) download
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index acc6e2bc31..4810c4a0f1 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4249,16 +4249,11 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <indexterm>
- <primary>SLRU</primary>
- </indexterm>
-
<para>
- <productname>PostgreSQL</productname> accesses certain on-disk information
- via <firstterm>SLRU</firstterm> (simple least-recently-used) caches.
- The <structname>pg_stat_slru</structname> view will contain
- one row for each tracked SLRU cache, showing statistics about access
- to cached pages.
+ The <structname>pg_stat_user_functions</structname> view will contain
+ one row for each tracked function, showing statistics about executions of
+ that function. The <xref linkend="guc-track-functions"/> parameter
+ controls exactly which functions are tracked.
</para>
<table id="pg-stat-slru-view" xreflabel="pg_stat_slru">
@@ -4362,11 +4357,16 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ <indexterm>
+ <primary>SLRU</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_user_functions</structname> view will contain
- one row for each tracked function, showing statistics about executions of
- that function. The <xref linkend="guc-track-functions"/> parameter
- controls exactly which functions are tracked.
+ <productname>PostgreSQL</productname> accesses certain on-disk information
+ via <firstterm>SLRU</firstterm> (simple least-recently-used) caches.
+ The <structname>pg_stat_slru</structname> view will contain
+ one row for each tracked SLRU cache, showing statistics about access
+ to cached pages.
</para>
</sect2>
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-20 02:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2020-05-20 02:05 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> In monitoring.sgml, there are the tables and corresponding descriptions
> for pg_stat_user_functions and pg_stat_slru views. I found that those
> descriptions are located in opposite places. For example, the description
> for pg_stat_user_functions wrongly comes just after the table for
> pg_stat_slru view. Attached patch fixes this issue.
Hm, I see your point, but I think there is a bigger problem here:
this entire section was written with great disregard for our normal
conventions of how to lay out text around tables. The standard thing,
as seen in Chapter 9 or the system catalog section, is that first
you have an introductory paragraph --- preferably containing an actual
link to the table --- then you have the table, and then if you feel a
need for any footnote-like comments on the table, you put those below it.
I seem to recall Peter E. explaining that this is important because some
presentations might put the table out-of-line entirely, so you should
have an <xref> to it.
What we've mostly got in 27.2 as it stands is that the explanations are
below the tables, which is just backwards. I think the discrepancy
you spotted is because I added some text about the pg_stat_slru view
and just automatically added it above the table, not noticing that that
wasn't what the surrounding stuff did.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-05-20 05:44 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-20 05:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/20 11:05, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> In monitoring.sgml, there are the tables and corresponding descriptions
>> for pg_stat_user_functions and pg_stat_slru views. I found that those
>> descriptions are located in opposite places. For example, the description
>> for pg_stat_user_functions wrongly comes just after the table for
>> pg_stat_slru view. Attached patch fixes this issue.
>
> Hm, I see your point, but I think there is a bigger problem here:
> this entire section was written with great disregard for our normal
> conventions of how to lay out text around tables. The standard thing,
> as seen in Chapter 9 or the system catalog section, is that first
> you have an introductory paragraph --- preferably containing an actual
> link to the table --- then you have the table, and then if you feel a
> need for any footnote-like comments on the table, you put those below it.
Yeah, I agree to change the layout that way.
Also I don't like that all the stats views are packed in one section
currently. Which makes the docs difficult to read, I'm afraid. Thought?
If we change the layout entirely, at the same time, what about separating
each view into different section by adding <sect2>?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-20 13:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2020-05-20 13:32 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> Also I don't like that all the stats views are packed in one section
> currently. Which makes the docs difficult to read, I'm afraid. Thought?
> If we change the layout entirely, at the same time, what about separating
> each view into different section by adding <sect2>?
OK by me --- that, too, would be more like the existing catalogs
chapter.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-05-20 18:26 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-20 18:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/20 22:32, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> Also I don't like that all the stats views are packed in one section
>> currently. Which makes the docs difficult to read, I'm afraid. Thought?
>> If we change the layout entirely, at the same time, what about separating
>> each view into different section by adding <sect2>?
>
> OK by me --- that, too, would be more like the existing catalogs
> chapter.
Yeah, so I'd like to propose the attached patch.
- 6644 | LWLock | ProcArrayLock
+ 6644 | LWLock | ProcArray
I found "ProcArrayLock" is still used in monitoring.sgml though
it was renamed to ProcArray. So the patch also includes the above change.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments:
monitoring_docfix.patch (text/plain, 23.5K) download
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index acc6e2bc31..41ac5d2b67 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -608,8 +608,22 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
into the kernel's handling of I/O.
</para>
+ </sect2>
- <table id="pg-stat-activity-view" xreflabel="pg_stat_activity">
+ <sect2 id="pg-stat-activity-view" xreflabel="pg_stat_activity">
+ <title><structname>pg_stat_activity</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_activity</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_activity</structname> view will have one row
+ per server process, showing information related to
+ the current activity of that process.
+ </para>
+
+ <table>
<title><structname>pg_stat_activity</structname> View</title>
<tgroup cols="1">
<thead>
@@ -889,12 +903,6 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</tgroup>
</table>
- <para>
- The <structname>pg_stat_activity</structname> view will have one row
- per server process, showing information related to
- the current activity of that process.
- </para>
-
<note>
<para>
The <structfield>wait_event</structfield> and <structfield>state</structfield> columns are
@@ -2135,15 +2143,31 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<programlisting>
SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
- pid | wait_event_type | wait_event
-------+-----------------+---------------
+ pid | wait_event_type | wait_event
+------+-----------------+------------
2540 | Lock | relation
- 6644 | LWLock | ProcArrayLock
+ 6644 | LWLock | ProcArray
(2 rows)
</programlisting>
</para>
- <table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
+ </sect2>
+
+ <sect2 id="pg-stat-replication-view" xreflabel="pg_stat_replication">
+ <title><structname>pg_stat_replication</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_replication</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_replication</structname> view will contain one row
+ per WAL sender process, showing statistics about replication to that
+ sender's connected standby server. Only directly connected standbys are
+ listed; no information is available about downstream standby servers.
+ </para>
+
+ <table>
<title><structname>pg_stat_replication</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2457,13 +2481,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_replication</structname> view will contain one row
- per WAL sender process, showing statistics about replication to that
- sender's connected standby server. Only directly connected standbys are
- listed; no information is available about downstream standby servers.
- </para>
-
<para>
The lag times reported in the <structname>pg_stat_replication</structname>
view are measurements of the time taken for recent WAL to be written,
@@ -2503,7 +2520,22 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</para>
</note>
- <table id="pg-stat-wal-receiver-view" xreflabel="pg_stat_wal_receiver">
+ </sect2>
+
+ <sect2 id="pg-stat-wal-receiver-view" xreflabel="pg_stat_wal_receiver">
+ <title><structname>pg_stat_wal_receiver</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_wal_receiver</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_wal_receiver</structname> view will contain only
+ one row, showing statistics about the WAL receiver from that receiver's
+ connected server.
+ </para>
+
+ <table>
<title><structname>pg_stat_wal_receiver</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2668,13 +2700,23 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-subscription" xreflabel="pg_stat_subscription">
+ <title><structname>pg_stat_subscription</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_subscription</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_wal_receiver</structname> view will contain only
- one row, showing statistics about the WAL receiver from that receiver's
- connected server.
+ The <structname>pg_stat_subscription</structname> view will contain one
+ row per subscription for main worker (with null PID if the worker is
+ not running), and additional rows for workers handling the initial data
+ copy of the subscribed tables.
</para>
- <table id="pg-stat-subscription" xreflabel="pg_stat_subscription">
+ <table>
<title><structname>pg_stat_subscription</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2776,14 +2818,25 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-ssl-view" xreflabel="pg_stat_ssl">
+ <title><structname>pg_stat_ssl</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_ssl</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_subscription</structname> view will contain one
- row per subscription for main worker (with null PID if the worker is
- not running), and additional rows for workers handling the initial data
- copy of the subscribed tables.
+ The <structname>pg_stat_ssl</structname> view will contain one row per
+ backend or WAL sender process, showing statistics about SSL usage on
+ this connection. It can be joined to <structname>pg_stat_activity</structname>
+ or <structname>pg_stat_replication</structname> on the
+ <structfield>pid</structfield> column to get more details about the
+ connection.
</para>
- <table id="pg-stat-ssl-view" xreflabel="pg_stat_ssl">
+ <table>
<title><structname>pg_stat_ssl</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2896,16 +2949,25 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-gssapi-view" xreflabel="pg_stat_gssapi">
+ <title><structname>pg_stat_gssapi</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_gssapi</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_ssl</structname> view will contain one row per
- backend or WAL sender process, showing statistics about SSL usage on
- this connection. It can be joined to <structname>pg_stat_activity</structname>
- or <structname>pg_stat_replication</structname> on the
+ The <structname>pg_stat_gssapi</structname> view will contain one row per
+ backend, showing information about GSSAPI usage on this connection. It can
+ be joined to <structname>pg_stat_activity</structname> or
+ <structname>pg_stat_replication</structname> on the
<structfield>pid</structfield> column to get more details about the
connection.
</para>
- <table id="pg-stat-gssapi-view" xreflabel="pg_stat_gssapi">
+ <table>
<title><structname>pg_stat_gssapi</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2962,17 +3024,21 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-archiver-view" xreflabel="pg_stat_archiver">
+ <title><structname>pg_stat_archiver</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_archiver</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_gssapi</structname> view will contain one row per
- backend, showing information about GSSAPI usage on this connection. It can
- be joined to <structname>pg_stat_activity</structname> or
- <structname>pg_stat_replication</structname> on the
- <structfield>pid</structfield> column to get more details about the
- connection.
+ The <structname>pg_stat_archiver</structname> view will always have a
+ single row, containing data about the archiver process of the cluster.
</para>
-
- <table id="pg-stat-archiver-view" xreflabel="pg_stat_archiver">
+ <table>
<title><structname>pg_stat_archiver</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3053,12 +3119,21 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-bgwriter-view" xreflabel="pg_stat_bgwriter">
+ <title><structname>pg_stat_bgwriter</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_bgwriter</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_archiver</structname> view will always have a
- single row, containing data about the archiver process of the cluster.
+ The <structname>pg_stat_bgwriter</structname> view will always have a
+ single row, containing global data for the cluster.
</para>
- <table id="pg-stat-bgwriter-view" xreflabel="pg_stat_bgwriter">
+ <table>
<title><structname>pg_stat_bgwriter</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3181,12 +3256,22 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-database-view" xreflabel="pg_stat_database">
+ <title><structname>pg_stat_database</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_database</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_bgwriter</structname> view will always have a
- single row, containing global data for the cluster.
+ The <structname>pg_stat_database</structname> view will contain one row
+ for each database in the cluster, plus one for shared objects, showing
+ database-wide statistics.
</para>
- <table id="pg-stat-database-view" xreflabel="pg_stat_database">
+ <table>
<title><structname>pg_stat_database</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3416,13 +3501,24 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
+ <title><structname>pg_stat_database_conflicts</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_database_conflicts</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_database</structname> view will contain one row
- for each database in the cluster, plus one for shared objects, showing
- database-wide statistics.
+ The <structname>pg_stat_database_conflicts</structname> view will contain
+ one row per database, showing database-wide statistics about
+ query cancels occurring due to conflicts with recovery on standby servers.
+ This view will only contain information on standby servers, since
+ conflicts do not occur on master servers.
</para>
- <table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
+ <table>
<title><structname>pg_stat_database_conflicts</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3508,15 +3604,26 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
+ <title><structname>pg_stat_all_tables</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_all_tables</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_database_conflicts</structname> view will contain
- one row per database, showing database-wide statistics about
- query cancels occurring due to conflicts with recovery on standby servers.
- This view will only contain information on standby servers, since
- conflicts do not occur on master servers.
+ The <structname>pg_stat_all_tables</structname> view will contain
+ one row for each table in the current database (including TOAST
+ tables), showing statistics about accesses to that specific table. The
+ <structname>pg_stat_user_tables</structname> and
+ <structname>pg_stat_sys_tables</structname> views
+ contain the same information,
+ but filtered to only show user and system tables respectively.
</para>
- <table id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
+ <table>
<title><structname>pg_stat_all_tables</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3748,17 +3855,26 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-all-indexes-view" xreflabel="pg_stat_all_indexes">
+ <title><structname>pg_stat_all_indexes</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_all_indexes</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_all_tables</structname> view will contain
- one row for each table in the current database (including TOAST
- tables), showing statistics about accesses to that specific table. The
- <structname>pg_stat_user_tables</structname> and
- <structname>pg_stat_sys_tables</structname> views
+ The <structname>pg_stat_all_indexes</structname> view will contain
+ one row for each index in the current database,
+ showing statistics about accesses to that specific index. The
+ <structname>pg_stat_user_indexes</structname> and
+ <structname>pg_stat_sys_indexes</structname> views
contain the same information,
- but filtered to only show user and system tables respectively.
+ but filtered to only show user and system indexes respectively.
</para>
- <table id="pg-stat-all-indexes-view" xreflabel="pg_stat_all_indexes">
+ <table>
<title><structname>pg_stat_all_indexes</structname> View</title>
<tgroup cols="1">
<thead>
@@ -3849,16 +3965,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_all_indexes</structname> view will contain
- one row for each index in the current database,
- showing statistics about accesses to that specific index. The
- <structname>pg_stat_user_indexes</structname> and
- <structname>pg_stat_sys_indexes</structname> views
- contain the same information,
- but filtered to only show user and system indexes respectively.
- </para>
-
<para>
Indexes can be used by simple index scans, <quote>bitmap</quote> index scans,
and the optimizer. In a bitmap scan
@@ -3888,7 +3994,26 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</para>
</note>
- <table id="pg-statio-all-tables-view" xreflabel="pg_statio_all_tables">
+ </sect2>
+
+ <sect2 id="pg-statio-all-tables-view" xreflabel="pg_statio_all_tables">
+ <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>
<title><structname>pg_statio_all_tables</structname> View</title>
<tgroup cols="1">
<thead>
@@ -4005,96 +4130,14 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <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>
+ </sect2>
- <table id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
- <title><structname>pg_statio_all_indexes</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>
+ <sect2 id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
+ <title><structname>pg_statio_all_indexes</structname></title>
- <tbody>
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>relid</structfield> <type>oid</type>
- </para>
- <para>
- OID of the table for this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>indexrelid</structfield> <type>oid</type>
- </para>
- <para>
- OID of this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>schemaname</structfield> <type>name</type>
- </para>
- <para>
- Name of the schema this index is in
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>relname</structfield> <type>name</type>
- </para>
- <para>
- Name of the table for this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>indexrelname</structfield> <type>name</type>
- </para>
- <para>
- Name of this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>idx_blks_read</structfield> <type>bigint</type>
- </para>
- <para>
- Number of disk blocks read from this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>idx_blks_hit</structfield> <type>bigint</type>
- </para>
- <para>
- Number of buffer hits in this index
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
+ <indexterm>
+ <primary>pg_statio_all_indexes</primary>
+ </indexterm>
<para>
The <structname>pg_statio_all_indexes</structname> view will contain
@@ -4106,7 +4149,103 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
but filtered to only show user and system indexes respectively.
</para>
- <table id="pg-statio-all-sequences-view" xreflabel="pg_statio_all_sequences">
+ <table>
+ <title><structname>pg_statio_all_indexes</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>
+ OID of the table for this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>indexrelid</structfield> <type>oid</type>
+ </para>
+ <para>
+ OID of this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>schemaname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of the schema this index is in
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>relname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of the table for this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>indexrelname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>idx_blks_read</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Number of disk blocks read from this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>idx_blks_hit</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Number of buffer hits in this index
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="pg-statio-all-sequences-view" xreflabel="pg_statio_all_sequences">
+ <title><structname>pg_statio_all_sequences</structname></title>
+
+ <indexterm>
+ <primary>pg_statio_all_sequences</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_statio_all_sequences</structname> view will contain
+ one row for each sequence in the current database,
+ showing statistics about I/O on that specific sequence.
+ </para>
+
+ <table>
<title><structname>pg_statio_all_sequences</structname> View</title>
<tgroup cols="1">
<thead>
@@ -4169,13 +4308,23 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-user-functions-view" xreflabel="pg_stat_user_functions">
+ <title><structname>pg_stat_user_functions</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_user_functions</primary>
+ </indexterm>
+
<para>
- The <structname>pg_statio_all_sequences</structname> view will contain
- one row for each sequence in the current database,
- showing statistics about I/O on that specific sequence.
+ The <structname>pg_stat_user_functions</structname> view will contain
+ one row for each tracked function, showing statistics about executions of
+ that function. The <xref linkend="guc-track-functions"/> parameter
+ controls exactly which functions are tracked.
</para>
- <table id="pg-stat-user-functions-view" xreflabel="pg_stat_user_functions">
+ <table>
<title><structname>pg_stat_user_functions</structname> View</title>
<tgroup cols="1">
<thead>
@@ -4249,10 +4398,19 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="pg-stat-slru-view" xreflabel="pg_stat_slru">
+ <title><structname>pg_stat_slru</structname></title>
+
<indexterm>
<primary>SLRU</primary>
</indexterm>
+ <indexterm>
+ <primary>pg_stat_slru</primary>
+ </indexterm>
+
<para>
<productname>PostgreSQL</productname> accesses certain on-disk information
via <firstterm>SLRU</firstterm> (simple least-recently-used) caches.
@@ -4261,7 +4419,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
to cached pages.
</para>
- <table id="pg-stat-slru-view" xreflabel="pg_stat_slru">
+ <table>
<title><structname>pg_stat_slru</structname> View</title>
<tgroup cols="1">
<thead>
@@ -4362,13 +4520,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_user_functions</structname> view will contain
- one row for each tracked function, showing statistics about executions of
- that function. The <xref linkend="guc-track-functions"/> parameter
- controls exactly which functions are tracked.
- </para>
-
</sect2>
<sect2 id="monitoring-stats-functions">
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-20 19:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-22 13:35 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2020-05-20 19:53 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> On 2020/05/20 22:32, Tom Lane wrote:
>> OK by me --- that, too, would be more like the existing catalogs
>> chapter.
> Yeah, so I'd like to propose the attached patch.
Hmmm ... I'm not exactly convinced about sticking xreflabels onto
the <sect2>s as you've done here. Presumably that would make <xref>s
render like "pg_stat_slru" not "Section 27.2.3", which I think is
not consistent with our practice elsewhere. I'd be inclined to
leave the id attributes on the <table>s, and add xreflabels there
if we want them.
I see that catalogs.sgml doesn't really match either of those approaches,
though. Not sure if we want to change it. It looks like people have
tended to use <link> to substitute text for xref's to the catalog
sections, so maybe it would be better to add xreflabels there too
and simplify the references.
Other than that markup quibble, this looks fine to me.
> - 6644 | LWLock | ProcArrayLock
> + 6644 | LWLock | ProcArray
> I found "ProcArrayLock" is still used in monitoring.sgml though
> it was renamed to ProcArray. So the patch also includes the above change.
Ooops, my oversight.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-05-22 13:35 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-25 05:23 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-22 13:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/21 4:53, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> On 2020/05/20 22:32, Tom Lane wrote:
>>> OK by me --- that, too, would be more like the existing catalogs
>>> chapter.
>
>> Yeah, so I'd like to propose the attached patch.
>
> Hmmm ... I'm not exactly convinced about sticking xreflabels onto
> the <sect2>s as you've done here. Presumably that would make <xref>s
> render like "pg_stat_slru" not "Section 27.2.3", which I think is
> not consistent with our practice elsewhere. I'd be inclined to
> leave the id attributes on the <table>s, and add xreflabels there
> if we want them.
>
> I see that catalogs.sgml doesn't really match either of those approaches,
> though. Not sure if we want to change it. It looks like people have
> tended to use <link> to substitute text for xref's to the catalog
> sections, so maybe it would be better to add xreflabels there too
> and simplify the references.
Yeah, since I think that using <xref> is simpler than <link>, I added xlabel
in <sect2>. But if we don't do that for the consistency with catalog.sgml,
I think that there are two approaches.
(1) Replace <xref> with <link> when referencing to the monitoring views
docs. For example, add <sect2 id="monitoring-pg-stat-relication-view">
and replace <xref linkend="pg-stat-replication-view"/> with
<link linkend="monitoring-pg-stat-replication-view">.
(2) Leave <xref> as it is. In this case, for example,
<xref linkend="pg-stat-replication-view"/> references to the table
of pg_stat_replication instead of the section.
I prefer (1) because it's better to reference to the section rather than
the table. There are thirty <xref> for monitoring views in the docs and
they need to be updated.
>
> Other than that markup quibble, this looks fine to me.
Thanks for the review!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-22 13:35 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-25 05:23 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-27 03:17 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-25 05:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/22 22:35, Fujii Masao wrote:
>
>
> On 2020/05/21 4:53, Tom Lane wrote:
>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>> On 2020/05/20 22:32, Tom Lane wrote:
>>>> OK by me --- that, too, would be more like the existing catalogs
>>>> chapter.
>>
>>> Yeah, so I'd like to propose the attached patch.
>>
>> Hmmm ... I'm not exactly convinced about sticking xreflabels onto
>> the <sect2>s as you've done here. Presumably that would make <xref>s
>> render like "pg_stat_slru" not "Section 27.2.3", which I think is
>> not consistent with our practice elsewhere. I'd be inclined to
>> leave the id attributes on the <table>s, and add xreflabels there
>> if we want them.
>>
>> I see that catalogs.sgml doesn't really match either of those approaches,
>> though. Not sure if we want to change it. It looks like people have
>> tended to use <link> to substitute text for xref's to the catalog
>> sections, so maybe it would be better to add xreflabels there too
>> and simplify the references.
>
> Yeah, since I think that using <xref> is simpler than <link>, I added xlabel
> in <sect2>. But if we don't do that for the consistency with catalog.sgml,
> I think that there are two approaches.
>
> (1) Replace <xref> with <link> when referencing to the monitoring views
> docs. For example, add <sect2 id="monitoring-pg-stat-relication-view">
> and replace <xref linkend="pg-stat-replication-view"/> with
> <link linkend="monitoring-pg-stat-replication-view">.
>
> (2) Leave <xref> as it is. In this case, for example,
> <xref linkend="pg-stat-replication-view"/> references to the table
> of pg_stat_replication instead of the section.
>
> I prefer (1) because it's better to reference to the section rather than
> the table. There are thirty <xref> for monitoring views in the docs and
> they need to be updated.
Attached (monitoring_docfix_v2.patch) is the patch for (1).
I also attached the patch (update_release_note_for_monitoring_stats_views_v1.patch)
that updates the tags referencing to pg_stat_xxx views in release note.
I will propose this to Bruce if we can agree with the changes in monitoring.sgml.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments: download all (2 files, .tar.gz)
monitoring_docfix_v2.patch (text/plain, 39.1K) download
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 9851ef2713..632e6d23f7 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -10455,8 +10455,9 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
<para>
The <structfield>pid</structfield> column can be joined to the
- <structfield>pid</structfield> column of the <link
- linkend="pg-stat-activity-view"><structname>pg_stat_activity</structname></link>
+ <structfield>pid</structfield> column of the
+ <link linkend="monitoring-pg-stat-activity-view">
+ <structname>pg_stat_activity</structname></link>
view to get more
information on the session holding or awaiting each lock,
for example
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a2694e548a..4eef970d41 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3889,9 +3889,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
The synchronous standbys will be those whose names appear
in this list, and
that are both currently connected and streaming data in real-time
- (as shown by a state of <literal>streaming</literal> in the <link
- linkend="pg-stat-replication-view"><literal>pg_stat_replication</literal></link>
- view).
+ (as shown by a state of <literal>streaming</literal> in the
+ <link linkend="monitoring-pg-stat-replication-view">
+ <structname>pg_stat_replication</structname></link> view).
Specifying more than one synchronous standby can allow for very high
availability and protection against data loss.
</para>
@@ -4244,8 +4244,8 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
Specifies the minimum frequency for the WAL receiver
process on the standby to send information about replication progress
to the primary or upstream standby, where it can be seen using the
- <link
- linkend="pg-stat-replication-view"><literal>pg_stat_replication</literal></link>
+ <link linkend="monitoring-pg-stat-replication-view">
+ <structname>pg_stat_replication</structname></link>
view. The standby will report
the last write-ahead log location it has written, the last position it
has flushed to disk, and the last position it has applied.
@@ -6694,8 +6694,10 @@ local0.* /var/log/postgresql
<para>
The backend type corresponds to the column
- <structfield>backend_type</structfield> in the view <xref
- linkend="pg-stat-activity-view"/>, but additional types can appear
+ <structfield>backend_type</structfield> in the view
+ <link linkend="monitoring-pg-stat-activity-view">
+ <structname>pg_stat_activity</structname></link>,
+ but additional types can appear
in the log that don't show in that view.
</para>
@@ -7191,7 +7193,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
platforms. You can use the <xref linkend="pgtesttiming"/> tool to
measure the overhead of timing on your system.
I/O timing information is
- displayed in <xref linkend="pg-stat-database-view"/>, in the output of
+ displayed in <link linkend="monitoring-pg-stat-database-view">
+ <structname>pg_stat_database</structname></link>, in the output of
<xref linkend="sql-explain"/> when the <literal>BUFFERS</literal> option is
used, and by <xref linkend="pgstatstatements"/>. Only superusers can
change this setting.
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 805e100055..65c3fc62a9 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -895,7 +895,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</para>
<para>
You can retrieve a list of WAL sender processes via the
- <xref linkend="pg-stat-replication-view"/> view. Large differences between
+ <link linkend="monitoring-pg-stat-replication-view"><structname>
+ pg_stat_replication</structname></link> view. Large differences between
<function>pg_current_wal_lsn</function> and the view's <literal>sent_lsn</literal> field
might indicate that the master server is under heavy load, while
differences between <literal>sent_lsn</literal> and
@@ -904,7 +905,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</para>
<para>
On a hot standby, the status of the WAL receiver process can be retrieved
- via the <xref linkend="pg-stat-wal-receiver-view"/> view. A large
+ via the <link linkend="monitoring-pg-stat-wal-receiver-view">
+ <structname>pg_stat_wal_receiver</structname></link> view. A large
difference between <function>pg_last_wal_replay_lsn</function> and the
view's <literal>flushed_lsn</literal> indicates that WAL is being
received faster than it can be replayed.
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index eba331a72b..e19bb3fd65 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -495,7 +495,8 @@
<para>
The monitoring information about subscription is visible in
- <link linkend="pg-stat-subscription"><literal>pg_stat_subscription</literal></link>.
+ <link linkend="monitoring-pg-stat-subscription">
+ <structname>pg_stat_subscription</structname></link>.
This view contains one row for every subscription worker. A subscription
can have zero or more active subscription workers depending on its state.
</para>
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index bad3bfe620..c89f93cf6b 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -347,7 +347,8 @@ $ pg_recvlogical -d postgres --slot=test --drop-slot
<para>
The <link linkend="view-pg-replication-slots"><structname>pg_replication_slots</structname></link>
view and the
- <link linkend="pg-stat-replication-view"><structname>pg_stat_replication</structname></link>
+ <link linkend="monitoring-pg-stat-replication-view">
+ <structname>pg_stat_replication</structname></link>
view provide information about the current state of replication slots and
streaming replication connections respectively. These views apply to both physical and
logical replication.
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 49d4bb13b9..321a0f4bb1 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -300,7 +300,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row per server process, showing information related to
the current activity of that process, such as state and current query.
- See <xref linkend="pg-stat-activity-view"/> for details.
+ See <link linkend="monitoring-pg-stat-activity-view">
+ <structname>pg_stat_activity</structname></link> for details.
</entry>
</row>
@@ -308,7 +309,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_replication</structname><indexterm><primary>pg_stat_replication</primary></indexterm></entry>
<entry>One row per WAL sender process, showing statistics about
replication to that sender's connected standby server.
- See <xref linkend="pg-stat-replication-view"/> for details.
+ See <link linkend="monitoring-pg-stat-replication-view">
+ <structname>pg_stat_replication</structname></link> for details.
</entry>
</row>
@@ -316,7 +318,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_wal_receiver</structname><indexterm><primary>pg_stat_wal_receiver</primary></indexterm></entry>
<entry>Only one row, showing statistics about the WAL receiver from
that receiver's connected server.
- See <xref linkend="pg-stat-wal-receiver-view"/> for details.
+ See <link linkend="monitoring-pg-stat-wal-receiver-view">
+ <structname>pg_stat_wal_receiver</structname></link> for details.
</entry>
</row>
@@ -324,7 +327,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_subscription</structname><indexterm><primary>pg_stat_subscription</primary></indexterm></entry>
<entry>At least one row per subscription, showing information about
the subscription workers.
- See <xref linkend="pg-stat-subscription"/> for details.
+ See <link linkend="monitoring-pg-stat-subscription">
+ <structname>pg_stat_subscription</structname></link> for details.
</entry>
</row>
@@ -332,7 +336,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_ssl</structname><indexterm><primary>pg_stat_ssl</primary></indexterm></entry>
<entry>One row per connection (regular and replication), showing information about
SSL used on this connection.
- See <xref linkend="pg-stat-ssl-view"/> for details.
+ See <link linkend="monitoring-pg-stat-ssl-view">
+ <structname>pg_stat_ssl</structname></link> for details.
</entry>
</row>
@@ -340,7 +345,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_gssapi</structname><indexterm><primary>pg_stat_gssapi</primary></indexterm></entry>
<entry>One row per connection (regular and replication), showing information about
GSSAPI authentication and encryption used on this connection.
- See <xref linkend="pg-stat-gssapi-view"/> for details.
+ See <link linkend="monitoring-pg-stat-gssapi-view">
+ <structname>pg_stat_gssapi</structname></link> for details.
</entry>
</row>
@@ -404,7 +410,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_archiver</structname><indexterm><primary>pg_stat_archiver</primary></indexterm></entry>
<entry>One row only, showing statistics about the
WAL archiver process's activity. See
- <xref linkend="pg-stat-archiver-view"/> for details.
+ <link linkend="monitoring-pg-stat-archiver-view">
+ <structname>pg_stat_archiver</structname></link> for details.
</entry>
</row>
@@ -412,14 +419,16 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_bgwriter</structname><indexterm><primary>pg_stat_bgwriter</primary></indexterm></entry>
<entry>One row only, showing statistics about the
background writer process's activity. See
- <xref linkend="pg-stat-bgwriter-view"/> for details.
+ <link linkend="monitoring-pg-stat-bgwriter-view">
+ <structname>pg_stat_bgwriter</structname></link> for details.
</entry>
</row>
<row>
<entry><structname>pg_stat_database</structname><indexterm><primary>pg_stat_database</primary></indexterm></entry>
<entry>One row per database, showing database-wide statistics. See
- <xref linkend="pg-stat-database-view"/> for details.
+ <link linkend="monitoring-pg-stat-database-view">
+ <structname>pg_stat_database</structname></link> for details.
</entry>
</row>
@@ -428,7 +437,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row per database, showing database-wide statistics about
query cancels due to conflict with recovery on standby servers.
- See <xref linkend="pg-stat-database-conflicts-view"/> for details.
+ See <link linkend="monitoring-pg-stat-database-conflicts-view">
+ <structname>pg_stat_database_conflicts</structname></link> for details.
</entry>
</row>
@@ -437,7 +447,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each table in the current database, showing statistics
about accesses to that specific table.
- See <xref linkend="pg-stat-all-tables-view"/> for details.
+ See <link linkend="monitoring-pg-stat-all-tables-view">
+ <structname>pg_stat_all_tables</structname></link> for details.
</entry>
</row>
@@ -479,7 +490,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each index in the current database, showing statistics
about accesses to that specific index.
- See <xref linkend="pg-stat-all-indexes-view"/> for details.
+ See <link linkend="monitoring-pg-stat-all-indexes-view">
+ <structname>pg_stat_all_indexes</structname></link> for details.
</entry>
</row>
@@ -500,7 +512,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each table in the current database, showing statistics
about I/O on that specific table.
- See <xref linkend="pg-statio-all-tables-view"/> for details.
+ See <link linkend="monitoring-pg-statio-all-tables-view">
+ <structname>pg_statio_all_tables</structname></link> for details.
</entry>
</row>
@@ -521,7 +534,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each index in the current database,
showing statistics about I/O on that specific index.
- See <xref linkend="pg-statio-all-indexes-view"/> for details.
+ See <link linkend="monitoring-pg-statio-all-indexes-view">
+ <structname>pg_statio_all_indexes</structname></link> for details.
</entry>
</row>
@@ -542,7 +556,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each sequence in the current database,
showing statistics about I/O on that specific sequence.
- See <xref linkend="pg-statio-all-sequences-view"/> for details.
+ See <link linkend="monitoring-pg-statio-all-sequences-view">
+ <structname>pg_statio_all_sequences</structname></link> for details.
</entry>
</row>
@@ -564,7 +579,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry>
One row for each tracked function, showing statistics
about executions of that function. See
- <xref linkend="pg-stat-user-functions-view"/> for details.
+ <link linkend="monitoring-pg-stat-user-functions-view">
+ <structname>pg_stat_user_functions</structname></link> for details.
</entry>
</row>
@@ -578,7 +594,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<row>
<entry><structname>pg_stat_slru</structname><indexterm><primary>pg_stat_slru</primary></indexterm></entry>
<entry>One row per SLRU, showing statistics of operations. See
- <xref linkend="pg-stat-slru-view"/> for details.
+ <link linkend="monitoring-pg-stat-slru-view">
+ <structname>pg_stat_slru</structname></link> for details.
</entry>
</row>
@@ -608,6 +625,20 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
into the kernel's handling of I/O.
</para>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-activity-view">
+ <title><structname>pg_stat_activity</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_activity</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_activity</structname> view will have one row
+ per server process, showing information related to
+ the current activity of that process.
+ </para>
<table id="pg-stat-activity-view" xreflabel="pg_stat_activity">
<title><structname>pg_stat_activity</structname> View</title>
@@ -889,12 +920,6 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</tgroup>
</table>
- <para>
- The <structname>pg_stat_activity</structname> view will have one row
- per server process, showing information related to
- the current activity of that process.
- </para>
-
<note>
<para>
The <structfield>wait_event</structfield> and <structfield>state</structfield> columns are
@@ -2135,14 +2160,30 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<programlisting>
SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
- pid | wait_event_type | wait_event
-------+-----------------+---------------
+ pid | wait_event_type | wait_event
+------+-----------------+------------
2540 | Lock | relation
- 6644 | LWLock | ProcArrayLock
+ 6644 | LWLock | ProcArray
(2 rows)
</programlisting>
</para>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-replication-view">
+ <title><structname>pg_stat_replication</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_replication</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_replication</structname> view will contain one row
+ per WAL sender process, showing statistics about replication to that
+ sender's connected standby server. Only directly connected standbys are
+ listed; no information is available about downstream standby servers.
+ </para>
+
<table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
<title><structname>pg_stat_replication</structname> View</title>
<tgroup cols="1">
@@ -2457,13 +2498,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_replication</structname> view will contain one row
- per WAL sender process, showing statistics about replication to that
- sender's connected standby server. Only directly connected standbys are
- listed; no information is available about downstream standby servers.
- </para>
-
<para>
The lag times reported in the <structname>pg_stat_replication</structname>
view are measurements of the time taken for recent WAL to be written,
@@ -2503,6 +2537,21 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</para>
</note>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-wal-receiver-view">
+ <title><structname>pg_stat_wal_receiver</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_wal_receiver</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_stat_wal_receiver</structname> view will contain only
+ one row, showing statistics about the WAL receiver from that receiver's
+ connected server.
+ </para>
+
<table id="pg-stat-wal-receiver-view" xreflabel="pg_stat_wal_receiver">
<title><structname>pg_stat_wal_receiver</structname> View</title>
<tgroup cols="1">
@@ -2668,10 +2717,20 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-subscription">
+ <title><structname>pg_stat_subscription</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_subscription</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_wal_receiver</structname> view will contain only
- one row, showing statistics about the WAL receiver from that receiver's
- connected server.
+ The <structname>pg_stat_subscription</structname> view will contain one
+ row per subscription for main worker (with null PID if the worker is
+ not running), and additional rows for workers handling the initial data
+ copy of the subscribed tables.
</para>
<table id="pg-stat-subscription" xreflabel="pg_stat_subscription">
@@ -2776,11 +2835,22 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-ssl-view">
+ <title><structname>pg_stat_ssl</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_ssl</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_subscription</structname> view will contain one
- row per subscription for main worker (with null PID if the worker is
- not running), and additional rows for workers handling the initial data
- copy of the subscribed tables.
+ The <structname>pg_stat_ssl</structname> view will contain one row per
+ backend or WAL sender process, showing statistics about SSL usage on
+ this connection. It can be joined to <structname>pg_stat_activity</structname>
+ or <structname>pg_stat_replication</structname> on the
+ <structfield>pid</structfield> column to get more details about the
+ connection.
</para>
<table id="pg-stat-ssl-view" xreflabel="pg_stat_ssl">
@@ -2896,11 +2966,20 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-gssapi-view">
+ <title><structname>pg_stat_gssapi</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_gssapi</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_ssl</structname> view will contain one row per
- backend or WAL sender process, showing statistics about SSL usage on
- this connection. It can be joined to <structname>pg_stat_activity</structname>
- or <structname>pg_stat_replication</structname> on the
+ The <structname>pg_stat_gssapi</structname> view will contain one row per
+ backend, showing information about GSSAPI usage on this connection. It can
+ be joined to <structname>pg_stat_activity</structname> or
+ <structname>pg_stat_replication</structname> on the
<structfield>pid</structfield> column to get more details about the
connection.
</para>
@@ -2962,16 +3041,20 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-archiver-view">
+ <title><structname>pg_stat_archiver</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_archiver</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_gssapi</structname> view will contain one row per
- backend, showing information about GSSAPI usage on this connection. It can
- be joined to <structname>pg_stat_activity</structname> or
- <structname>pg_stat_replication</structname> on the
- <structfield>pid</structfield> column to get more details about the
- connection.
+ The <structname>pg_stat_archiver</structname> view will always have a
+ single row, containing data about the archiver process of the cluster.
</para>
-
<table id="pg-stat-archiver-view" xreflabel="pg_stat_archiver">
<title><structname>pg_stat_archiver</structname> View</title>
<tgroup cols="1">
@@ -3053,9 +3136,18 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-bgwriter-view">
+ <title><structname>pg_stat_bgwriter</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_bgwriter</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_archiver</structname> view will always have a
- single row, containing data about the archiver process of the cluster.
+ The <structname>pg_stat_bgwriter</structname> view will always have a
+ single row, containing global data for the cluster.
</para>
<table id="pg-stat-bgwriter-view" xreflabel="pg_stat_bgwriter">
@@ -3181,9 +3273,19 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-database-view">
+ <title><structname>pg_stat_database</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_database</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_bgwriter</structname> view will always have a
- single row, containing global data for the cluster.
+ The <structname>pg_stat_database</structname> view will contain one row
+ for each database in the cluster, plus one for shared objects, showing
+ database-wide statistics.
</para>
<table id="pg-stat-database-view" xreflabel="pg_stat_database">
@@ -3325,7 +3427,8 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
<para>
Number of queries canceled due to conflicts with recovery
in this database. (Conflicts occur only on standby servers; see
- <xref linkend="pg-stat-database-conflicts-view"/> for details.)
+ <link linkend="monitoring-pg-stat-database-conflicts-view">
+ <structname>pg_stat_database_conflicts</structname></link> for details.)
</para></entry>
</row>
@@ -3418,10 +3521,21 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-database-conflicts-view">
+ <title><structname>pg_stat_database_conflicts</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_database_conflicts</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_database</structname> view will contain one row
- for each database in the cluster, plus one for shared objects, showing
- database-wide statistics.
+ The <structname>pg_stat_database_conflicts</structname> view will contain
+ one row per database, showing database-wide statistics about
+ query cancels occurring due to conflicts with recovery on standby servers.
+ This view will only contain information on standby servers, since
+ conflicts do not occur on master servers.
</para>
<table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
@@ -3510,12 +3624,23 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-all-tables-view">
+ <title><structname>pg_stat_all_tables</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_all_tables</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_database_conflicts</structname> view will contain
- one row per database, showing database-wide statistics about
- query cancels occurring due to conflicts with recovery on standby servers.
- This view will only contain information on standby servers, since
- conflicts do not occur on master servers.
+ The <structname>pg_stat_all_tables</structname> view will contain
+ one row for each table in the current database (including TOAST
+ tables), showing statistics about accesses to that specific table. The
+ <structname>pg_stat_user_tables</structname> and
+ <structname>pg_stat_sys_tables</structname> views
+ contain the same information,
+ but filtered to only show user and system tables respectively.
</para>
<table id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
@@ -3750,14 +3875,23 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-all-indexes-view">
+ <title><structname>pg_stat_all_indexes</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_all_indexes</primary>
+ </indexterm>
+
<para>
- The <structname>pg_stat_all_tables</structname> view will contain
- one row for each table in the current database (including TOAST
- tables), showing statistics about accesses to that specific table. The
- <structname>pg_stat_user_tables</structname> and
- <structname>pg_stat_sys_tables</structname> views
+ The <structname>pg_stat_all_indexes</structname> view will contain
+ one row for each index in the current database,
+ showing statistics about accesses to that specific index. The
+ <structname>pg_stat_user_indexes</structname> and
+ <structname>pg_stat_sys_indexes</structname> views
contain the same information,
- but filtered to only show user and system tables respectively.
+ but filtered to only show user and system indexes respectively.
</para>
<table id="pg-stat-all-indexes-view" xreflabel="pg_stat_all_indexes">
@@ -3851,16 +3985,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_all_indexes</structname> view will contain
- one row for each index in the current database,
- showing statistics about accesses to that specific index. The
- <structname>pg_stat_user_indexes</structname> and
- <structname>pg_stat_sys_indexes</structname> views
- contain the same information,
- but filtered to only show user and system indexes respectively.
- </para>
-
<para>
Indexes can be used by simple index scans, <quote>bitmap</quote> index scans,
and the optimizer. In a bitmap scan
@@ -3890,6 +4014,25 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</para>
</note>
+ </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">
@@ -4007,96 +4150,14 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <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>
+ </sect2>
- <table id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
- <title><structname>pg_statio_all_indexes</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>
+ <sect2 id="monitoring-pg-statio-all-indexes-view">
+ <title><structname>pg_statio_all_indexes</structname></title>
- <tbody>
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>relid</structfield> <type>oid</type>
- </para>
- <para>
- OID of the table for this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>indexrelid</structfield> <type>oid</type>
- </para>
- <para>
- OID of this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>schemaname</structfield> <type>name</type>
- </para>
- <para>
- Name of the schema this index is in
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>relname</structfield> <type>name</type>
- </para>
- <para>
- Name of the table for this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>indexrelname</structfield> <type>name</type>
- </para>
- <para>
- Name of this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>idx_blks_read</structfield> <type>bigint</type>
- </para>
- <para>
- Number of disk blocks read from this index
- </para></entry>
- </row>
-
- <row>
- <entry role="catalog_table_entry"><para role="column_definition">
- <structfield>idx_blks_hit</structfield> <type>bigint</type>
- </para>
- <para>
- Number of buffer hits in this index
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
+ <indexterm>
+ <primary>pg_statio_all_indexes</primary>
+ </indexterm>
<para>
The <structname>pg_statio_all_indexes</structname> view will contain
@@ -4108,6 +4169,102 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
but filtered to only show user and system indexes respectively.
</para>
+ <table id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
+ <title><structname>pg_statio_all_indexes</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>
+ OID of the table for this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>indexrelid</structfield> <type>oid</type>
+ </para>
+ <para>
+ OID of this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>schemaname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of the schema this index is in
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>relname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of the table for this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>indexrelname</structfield> <type>name</type>
+ </para>
+ <para>
+ Name of this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>idx_blks_read</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Number of disk blocks read from this index
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>idx_blks_hit</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Number of buffer hits in this index
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="monitoring-pg-statio-all-sequences-view">
+ <title><structname>pg_statio_all_sequences</structname></title>
+
+ <indexterm>
+ <primary>pg_statio_all_sequences</primary>
+ </indexterm>
+
+ <para>
+ The <structname>pg_statio_all_sequences</structname> view will contain
+ one row for each sequence in the current database,
+ showing statistics about I/O on that specific sequence.
+ </para>
+
<table id="pg-statio-all-sequences-view" xreflabel="pg_statio_all_sequences">
<title><structname>pg_statio_all_sequences</structname> View</title>
<tgroup cols="1">
@@ -4171,10 +4328,20 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-user-functions-view">
+ <title><structname>pg_stat_user_functions</structname></title>
+
+ <indexterm>
+ <primary>pg_stat_user_functions</primary>
+ </indexterm>
+
<para>
- The <structname>pg_statio_all_sequences</structname> view will contain
- one row for each sequence in the current database,
- showing statistics about I/O on that specific sequence.
+ The <structname>pg_stat_user_functions</structname> view will contain
+ one row for each tracked function, showing statistics about executions of
+ that function. The <xref linkend="guc-track-functions"/> parameter
+ controls exactly which functions are tracked.
</para>
<table id="pg-stat-user-functions-view" xreflabel="pg_stat_user_functions">
@@ -4251,10 +4418,19 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
+ </sect2>
+
+ <sect2 id="monitoring-pg-stat-slru-view">
+ <title><structname>pg_stat_slru</structname></title>
+
<indexterm>
<primary>SLRU</primary>
</indexterm>
+ <indexterm>
+ <primary>pg_stat_slru</primary>
+ </indexterm>
+
<para>
<productname>PostgreSQL</productname> accesses certain on-disk information
via <firstterm>SLRU</firstterm> (simple least-recently-used) caches.
@@ -4364,13 +4540,6 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
</tgroup>
</table>
- <para>
- The <structname>pg_stat_user_functions</structname> view will contain
- one row for each tracked function, showing statistics about executions of
- that function. The <xref linkend="guc-track-functions"/> parameter
- controls exactly which functions are tracked.
- </para>
-
</sect2>
<sect2 id="monitoring-stats-functions">
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
index a04a180165..63e148833f 100644
--- a/doc/src/sgml/ref/initdb.sgml
+++ b/doc/src/sgml/ref/initdb.sgml
@@ -219,7 +219,8 @@ PostgreSQL documentation
may incur a noticeable performance penalty. If set, checksums
are calculated for all objects, in all databases. All checksum
failures will be reported in the
- <xref linkend="pg-stat-database-view"/> view.
+ <link linkend="monitoring-pg-stat-database-view">
+ <structname>pg_stat_database</structname></link> view.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index 12fadabfb8..d31fb1ce92 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -533,7 +533,8 @@ PostgreSQL documentation
in a non-zero exit status. However, the base backup will not be
removed in such a case, as if the <option>--no-clean</option> option
had been used. Checksum verifications failures will also be reported
- in the <xref linkend="pg-stat-database-view"/> view.
+ in the <link linkend="monitoring-pg-stat-database-view">
+ <structname>pg_stat_database</structname></link> view.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/sslinfo.sgml b/doc/src/sgml/sslinfo.sgml
index 78ff83d642..c237d4ba95 100644
--- a/doc/src/sgml/sslinfo.sgml
+++ b/doc/src/sgml/sslinfo.sgml
@@ -16,7 +16,8 @@
<para>
Some of the information available through this module can also be obtained
- using the built-in system view <xref linkend="pg-stat-ssl-view"/>.
+ using the built-in system view <link linkend="monitoring-pg-stat-ssl-view">
+ <structname>pg_stat_ssl</structname></link>.
</para>
<para>
update_release_note_for_monitoring_stats_views_v1.patch (text/plain, 2.5K) download
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 66fd016257..953271862c 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml/release-13.sgml
@@ -127,15 +127,18 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
-->
<para>
- Prevent display of auxiliary processes in <xref
- linkend="pg-stat-ssl-view"/> and <xref linkend="pg-stat-gssapi-view"/>
+ Prevent display of auxiliary processes in
+ <link linkend="monitoring-pg-stat-ssl-view"><structname>pg_stat_ssl
+ </structname></link> and <link linkend="monitoring-pg-stat-gssapi-view">
+ <structname>pg_stat_gssapi</structname></link>
system views (Euler Taveira)
</para>
<para>
- Queries that join these views to <xref
- linkend="pg-stat-activity-view"/> and wish to see auxiliary processes
- will need to use left joins.
+ Queries that join these views to
+ <link linkend="monitoring-pg-stat-activity-view">
+ <structname>pg_stat_activity</structname></link> and wish to
+ see auxiliary processes will need to use left joins.
</para>
</listitem>
@@ -951,8 +954,10 @@ Author: Michael Paquier <michael@paquier.xyz>
-->
<para>
- Add <structfield>leader_pid</structfield> to <xref
- linkend="pg-stat-activity-view"/> to report parallel worker ownership
+ Add <structfield>leader_pid</structfield> to
+ <link linkend="monitoring-pg-stat-activity-view">
+ <structname>pg_stat_activity</structname></link>
+ to report parallel worker ownership
(Julien Rouhaud)
</para>
</listitem>
@@ -992,7 +997,7 @@ Author: Amit Kapila <akapila@postgresql.org>
<para>
Add columns to the <link
- linkend="monitoring-stats-dynamic-views-table"><structname>pg_stat_replication</structname></link>
+ linkend="monitoring-pg-stat-replication-view"><structname>pg_stat_replication</structname></link>
system view to report how much logical decoding information has been
spilled to disk (Tomas Vondra)
</para>
@@ -1019,7 +1024,7 @@ Author: Tomas Vondra <tomas.vondra@postgresql.org>
<para>
Create <link
- linkend="monitoring-stats-views-table"><structname>pg_stat_slru</structname></link>
+ linkend="monitoring-pg-stat-slru-view"><structname>pg_stat_slru</structname></link>
system view to monitor internal <acronym>SLRU</acronym> caches
(Tomas Vondra)
</para>
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-22 13:35 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-25 05:23 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-27 03:17 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-29 08:16 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2020-05-27 03:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/25 14:23, Fujii Masao wrote:
>
>
> On 2020/05/22 22:35, Fujii Masao wrote:
>>
>>
>> On 2020/05/21 4:53, Tom Lane wrote:
>>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>>> On 2020/05/20 22:32, Tom Lane wrote:
>>>>> OK by me --- that, too, would be more like the existing catalogs
>>>>> chapter.
>>>
>>>> Yeah, so I'd like to propose the attached patch.
>>>
>>> Hmmm ... I'm not exactly convinced about sticking xreflabels onto
>>> the <sect2>s as you've done here. Presumably that would make <xref>s
>>> render like "pg_stat_slru" not "Section 27.2.3", which I think is
>>> not consistent with our practice elsewhere. I'd be inclined to
>>> leave the id attributes on the <table>s, and add xreflabels there
>>> if we want them.
>>>
>>> I see that catalogs.sgml doesn't really match either of those approaches,
>>> though. Not sure if we want to change it. It looks like people have
>>> tended to use <link> to substitute text for xref's to the catalog
>>> sections, so maybe it would be better to add xreflabels there too
>>> and simplify the references.
>>
>> Yeah, since I think that using <xref> is simpler than <link>, I added xlabel
>> in <sect2>. But if we don't do that for the consistency with catalog.sgml,
>> I think that there are two approaches.
>>
>> (1) Replace <xref> with <link> when referencing to the monitoring views
>> docs. For example, add <sect2 id="monitoring-pg-stat-relication-view">
>> and replace <xref linkend="pg-stat-replication-view"/> with
>> <link linkend="monitoring-pg-stat-replication-view">.
>>
>> (2) Leave <xref> as it is. In this case, for example,
>> <xref linkend="pg-stat-replication-view"/> references to the table
>> of pg_stat_replication instead of the section.
>>
>> I prefer (1) because it's better to reference to the section rather than
>> the table. There are thirty <xref> for monitoring views in the docs and
>> they need to be updated.
>
> Attached (monitoring_docfix_v2.patch) is the patch for (1).
Barring any objection, I will commit this patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: descriptions of pg_stat_user_functions and pg_stat_slru
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Tom Lane <tgl@sss.pgh.pa.us>
2020-05-22 13:35 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-25 05:23 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-27 03:17 ` Re: descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
@ 2020-05-29 08:16 ` Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 0 replies; 10+ messages in thread
From: Fujii Masao @ 2020-05-29 08:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/05/27 12:17, Fujii Masao wrote:
>
>
> On 2020/05/25 14:23, Fujii Masao wrote:
>>
>>
>> On 2020/05/22 22:35, Fujii Masao wrote:
>>>
>>>
>>> On 2020/05/21 4:53, Tom Lane wrote:
>>>> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>>>>> On 2020/05/20 22:32, Tom Lane wrote:
>>>>>> OK by me --- that, too, would be more like the existing catalogs
>>>>>> chapter.
>>>>
>>>>> Yeah, so I'd like to propose the attached patch.
>>>>
>>>> Hmmm ... I'm not exactly convinced about sticking xreflabels onto
>>>> the <sect2>s as you've done here. Presumably that would make <xref>s
>>>> render like "pg_stat_slru" not "Section 27.2.3", which I think is
>>>> not consistent with our practice elsewhere. I'd be inclined to
>>>> leave the id attributes on the <table>s, and add xreflabels there
>>>> if we want them.
>>>>
>>>> I see that catalogs.sgml doesn't really match either of those approaches,
>>>> though. Not sure if we want to change it. It looks like people have
>>>> tended to use <link> to substitute text for xref's to the catalog
>>>> sections, so maybe it would be better to add xreflabels there too
>>>> and simplify the references.
>>>
>>> Yeah, since I think that using <xref> is simpler than <link>, I added xlabel
>>> in <sect2>. But if we don't do that for the consistency with catalog.sgml,
>>> I think that there are two approaches.
>>>
>>> (1) Replace <xref> with <link> when referencing to the monitoring views
>>> docs. For example, add <sect2 id="monitoring-pg-stat-relication-view">
>>> and replace <xref linkend="pg-stat-replication-view"/> with
>>> <link linkend="monitoring-pg-stat-replication-view">.
>>>
>>> (2) Leave <xref> as it is. In this case, for example,
>>> <xref linkend="pg-stat-replication-view"/> references to the table
>>> of pg_stat_replication instead of the section.
>>>
>>> I prefer (1) because it's better to reference to the section rather than
>>> the table. There are thirty <xref> for monitoring views in the docs and
>>> they need to be updated.
>>
>> Attached (monitoring_docfix_v2.patch) is the patch for (1).
>
> Barring any objection, I will commit this patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2020-05-29 08:16 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-05-20 01:29 descriptions of pg_stat_user_functions and pg_stat_slru Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 02:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 05:44 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 13:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-20 18:26 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-20 19:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-05-22 13:35 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-25 05:23 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-27 03:17 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-05-29 08:16 ` Fujii Masao <masao.fujii@oss.nttdata.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox