Order of views in stats docs
http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1.
Can somebody find or explain the order of the views in there? It's not
actually alphabetical, but it's also not logical. In particular, what
is pg_stat_replication doing second to last?
I would suggest we move pg_stat_replication up to directly under
pg_stat_activity, and move pg_stat_database_conflicts up to directly
under pg_stat_database. I think the rest makes reasonable sense.
Any objections to this? Can anybody spot a reason for why they are
where they are other than that it was just appended to the end of the
table without realizing the order that I'm missing now and am about to
break?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1.
Can somebody find or explain the order of the views in there? It's not
actually alphabetical, but it's also not logical. In particular, what
is pg_stat_replication doing second to last?
I would suggest we move pg_stat_replication up to directly under
pg_stat_activity, and move pg_stat_database_conflicts up to directly
under pg_stat_database. I think the rest makes reasonable sense.
Any objections to this? Can anybody spot a reason for why they are
where they are other than that it was just appended to the end of the
table without realizing the order that I'm missing now and am about to
break?
I agree that the last two items seem to be suffering from blindly-add-
it-to-the-end syndrome, which is a disease that runs rampant around here.
However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
where you ought to put a new item. This would result in grouping the
"all", "sys", and "user" views separately, rather than grouping those
variants of a view together ... but on reflection I'm not sure that
that'd be totally horrible.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/5/14 10:57 AM, Tom Lane wrote:
However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
where you ought to put a new item.
Yes, I think that property is important when developing in a loose
community.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/5/14, 2:43 PM, Peter Eisentraut wrote:
On 11/5/14 10:57 AM, Tom Lane wrote:
However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
where you ought to put a new item.Yes, I think that property is important when developing in a loose
community.
Couldn't we just stick a warning SGML comment at the end of the list? ISTM that's no more likely to be missed/ignored than noticing that the list happens to be alphabetical.
Perhaps the best solution is to split the list into different areas; one for database stats, another for table stats, etc.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 5, 2014 at 4:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1.
Can somebody find or explain the order of the views in there? It's not
actually alphabetical, but it's also not logical. In particular, what
is pg_stat_replication doing second to last?I would suggest we move pg_stat_replication up to directly under
pg_stat_activity, and move pg_stat_database_conflicts up to directly
under pg_stat_database. I think the rest makes reasonable sense.Any objections to this? Can anybody spot a reason for why they are
where they are other than that it was just appended to the end of the
table without realizing the order that I'm missing now and am about to
break?I agree that the last two items seem to be suffering from blindly-add-
it-to-the-end syndrome, which is a disease that runs rampant around here.However, should we consider the possibility of changing the table to
straight alphabetical ordering? I'm not as much in love with that
approach as some folks, but it does have the merit that it's always clear
where you ought to put a new item. This would result in grouping the
"all", "sys", and "user" views separately, rather than grouping those
variants of a view together ... but on reflection I'm not sure that
that'd be totally horrible.
That would at least make it very predictable, yes.
Another thought I had in that case is maybe we need to break out the
pg_stat_activity and pg_stat_replication views into their own table.
They are really the only two views that are different in a lot of
ways. Maybe call the splits "session statistics views" and "object
statistics views", instead of just "standard statistics views"? The
difference being that they show snapshots of *right now*, whereas all
the other views show accumulated statistics over time.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/6/14 6:16 AM, Magnus Hagander wrote:
Another thought I had in that case is maybe we need to break out the
pg_stat_activity and pg_stat_replication views into their own table.
They are really the only two views that are different in a lot of
ways. Maybe call the splits "session statistics views" and "object
statistics views", instead of just "standard statistics views"? The
difference being that they show snapshots of *right now*, whereas all
the other views show accumulated statistics over time.
Yeah, splitting this up a bit would help, too.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 11/6/14 6:16 AM, Magnus Hagander wrote:
Another thought I had in that case is maybe we need to break out the
pg_stat_activity and pg_stat_replication views into their own table.
They are really the only two views that are different in a lot of
ways. Maybe call the splits "session statistics views" and "object
statistics views", instead of just "standard statistics views"? The
difference being that they show snapshots of *right now*, whereas all
the other views show accumulated statistics over time.Yeah, splitting this up a bit would help, too.
Here's an initial run of this. It still feels wrong that we have the
dynamic views under "the statistics collector". Perhaps longterm we
should look at actually splitting them out to a completely different
sect1?
I only fixed the obvious parts in this - the split out, and the moving
of pg_stat_database_conflicts. But it's a first step at least.
Objections?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
stats_tables_reorg.patchtext/x-patch; charset=US-ASCII; name=stats_tables_reorg.patchDownload
*** a/doc/src/sgml/monitoring.sgml
--- b/doc/src/sgml/monitoring.sgml
***************
*** 147,155 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</para>
<para>
! <productname>PostgreSQL</productname> also supports reporting of the exact
! command currently being executed by other server processes. This
! facility is independent of the collector process.
</para>
<sect2 id="monitoring-stats-setup">
--- 147,157 ----
</para>
<para>
! <productname>PostgreSQL</productname> also supports reporting dynamic
! 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
! which other connections exist in the system. This facility is independent
! of the collector process.
</para>
<sect2 id="monitoring-stats-setup">
***************
*** 211,228 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</sect2>
<sect2 id="monitoring-stats-views">
! <title>Viewing Collected Statistics</title>
<para>
Several predefined views, listed in <xref
! linkend="monitoring-stats-views-table">, are available to show the results
of statistics collection. Alternatively, one can
build custom views using the underlying statistics functions, as discussed
in <xref linkend="monitoring-stats-functions">.
</para>
<para>
! When using the statistics to monitor current activity, it is important
to realize that the information does not update instantaneously.
Each individual server process transmits new statistical counts to
the collector just before going idle; so a query or transaction still in
--- 213,233 ----
</sect2>
<sect2 id="monitoring-stats-views">
! <title>Viewing Statistics</title>
<para>
Several predefined views, listed in <xref
! linkend="monitoring-stats-dynamic-views-table">, are available to show
! the current state of the system. There are also several other
! views, listed in <xref
! linkend="monitoring-stats-views-table">, available to show the results
of statistics collection. Alternatively, one can
build custom views using the underlying statistics functions, as discussed
in <xref linkend="monitoring-stats-functions">.
</para>
<para>
! When using the statistics to monitor collected data, it is important
to realize that the information does not update instantaneously.
Each individual server process transmits new statistical counts to
the collector just before going idle; so a query or transaction still in
***************
*** 263,270 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
stated above; instead they update continuously throughout the transaction.
</para>
! <table id="monitoring-stats-views-table">
! <title>Standard Statistics Views</title>
<tgroup cols="2">
<thead>
--- 268,275 ----
stated above; instead they update continuously throughout the transaction.
</para>
! <table id="monitoring-stats-dynamic-views-table">
! <title>Dynamic Statistics Views</title>
<tgroup cols="2">
<thead>
***************
*** 288,293 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
--- 293,322 ----
</row>
<row>
+ <entry><structname>pg_stat_replication</><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.
+ </entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="monitoring-stats-views-table">
+ <title>Collected Statistics Views</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>View Name</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
<entry><structname>pg_stat_archiver</><indexterm><primary>pg_stat_archiver</primary></indexterm></entry>
<entry>One row only, showing statistics about the
WAL archiver process's activity. See
***************
*** 311,316 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
--- 340,354 ----
</row>
<row>
+ <entry><structname>pg_stat_database_conflicts</><indexterm><primary>pg_stat_database_conflicts</primary></indexterm></entry>
+ <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.
+ </entry>
+ </row>
+
+ <row>
<entry><structname>pg_stat_all_tables</><indexterm><primary>pg_stat_all_tables</primary></indexterm></entry>
<entry>
One row for each table in the current database, showing statistics
***************
*** 453,475 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
yet included in <structname>pg_stat_user_functions</>).</entry>
</row>
- <row>
- <entry><structname>pg_stat_replication</><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.
- </entry>
- </row>
-
- <row>
- <entry><structname>pg_stat_database_conflicts</><indexterm><primary>pg_stat_database_conflicts</primary></indexterm></entry>
- <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.
- </entry>
- </row>
-
</tbody>
</tgroup>
</table>
--- 491,496 ----
***************
*** 684,689 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
--- 705,831 ----
</para>
</note>
+ <table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
+ <title><structname>pg_stat_replication</structname> View</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Column</entry>
+ <entry>Type</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><structfield>pid</></entry>
+ <entry><type>integer</></entry>
+ <entry>Process ID of a WAL sender process</entry>
+ </row>
+ <row>
+ <entry><structfield>usesysid</></entry>
+ <entry><type>oid</></entry>
+ <entry>OID of the user logged into this WAL sender process</entry>
+ </row>
+ <row>
+ <entry><structfield>usename</></entry>
+ <entry><type>name</></entry>
+ <entry>Name of the user logged into this WAL sender process</entry>
+ </row>
+ <row>
+ <entry><structfield>application_name</></entry>
+ <entry><type>text</></entry>
+ <entry>Name of the application that is connected
+ to this WAL sender</entry>
+ </row>
+ <row>
+ <entry><structfield>client_addr</></entry>
+ <entry><type>inet</></entry>
+ <entry>IP address of the client connected to this WAL sender.
+ If this field is null, it indicates that the client is
+ connected via a Unix socket on the server machine.
+ </entry>
+ </row>
+ <row>
+ <entry><structfield>client_hostname</></entry>
+ <entry><type>text</></entry>
+ <entry>Host name of the connected client, as reported by a
+ reverse DNS lookup of <structfield>client_addr</>. This field will
+ only be non-null for IP connections, and only when <xref
+ linkend="guc-log-hostname"> is enabled.
+ </entry>
+ </row>
+ <row>
+ <entry><structfield>client_port</></entry>
+ <entry><type>integer</></entry>
+ <entry>TCP port number that the client is using for communication
+ with this WAL sender, or <literal>-1</> if a Unix socket is used
+ </entry>
+ </row>
+ <row>
+ <entry><structfield>backend_start</></entry>
+ <entry><type>timestamp with time zone</></entry>
+ <entry>Time when this process was started, i.e., when the
+ client connected to this WAL sender
+ </entry>
+ </row>
+ <row>
+ <entry><structfield>backend_xmin</structfield></entry>
+ <entry><type>xid</type></entry>
+ <entry>This standby's <literal>xmin</> horizon reported
+ by <xref linkend="guc-hot-standby-feedback">.</entry>
+ </row>
+ <row>
+ <entry><structfield>state</></entry>
+ <entry><type>text</></entry>
+ <entry>Current WAL sender state</entry>
+ </row>
+ <row>
+ <entry><structfield>sent_location</></entry>
+ <entry><type>pg_lsn</></entry>
+ <entry>Last transaction log position sent on this connection</entry>
+ </row>
+ <row>
+ <entry><structfield>write_location</></entry>
+ <entry><type>pg_lsn</></entry>
+ <entry>Last transaction log position written to disk by this standby
+ server</entry>
+ </row>
+ <row>
+ <entry><structfield>flush_location</></entry>
+ <entry><type>pg_lsn</></entry>
+ <entry>Last transaction log position flushed to disk by this standby
+ server</entry>
+ </row>
+ <row>
+ <entry><structfield>replay_location</></entry>
+ <entry><type>pg_lsn</></entry>
+ <entry>Last transaction log position replayed into the database on this
+ standby server</entry>
+ </row>
+ <row>
+ <entry><structfield>sync_priority</></entry>
+ <entry><type>integer</></entry>
+ <entry>Priority of this standby server for being chosen as the
+ synchronous standby</entry>
+ </row>
+ <row>
+ <entry><structfield>sync_state</></entry>
+ <entry><type>text</></entry>
+ <entry>Synchronous state of this standby server</entry>
+ </row>
+ </tbody>
+ </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>
+
+
<table id="pg-stat-archiver-view" xreflabel="pg_stat_archiver">
<title><structname>pg_stat_archiver</structname> View</title>
***************
*** 965,970 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
--- 1107,1176 ----
for each database in the cluster, showing database-wide statistics.
</para>
+ <table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
+ <title><structname>pg_stat_database_conflicts</structname> View</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Column</entry>
+ <entry>Type</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><structfield>datid</></entry>
+ <entry><type>oid</></entry>
+ <entry>OID of a database</entry>
+ </row>
+ <row>
+ <entry><structfield>datname</></entry>
+ <entry><type>name</></entry>
+ <entry>Name of this database</entry>
+ </row>
+ <row>
+ <entry><structfield>confl_tablespace</></entry>
+ <entry><type>bigint</></entry>
+ <entry>Number of queries in this database that have been canceled due to
+ dropped tablespaces</entry>
+ </row>
+ <row>
+ <entry><structfield>confl_lock</></entry>
+ <entry><type>bigint</></entry>
+ <entry>Number of queries in this database that have been canceled due to
+ lock timeouts</entry>
+ </row>
+ <row>
+ <entry><structfield>confl_snapshot</></entry>
+ <entry><type>bigint</></entry>
+ <entry>Number of queries in this database that have been canceled due to
+ old snapshots</entry>
+ </row>
+ <row>
+ <entry><structfield>confl_bufferpin</></entry>
+ <entry><type>bigint</></entry>
+ <entry>Number of queries in this database that have been canceled due to
+ pinned buffers</entry>
+ </row>
+ <row>
+ <entry><structfield>confl_deadlock</></entry>
+ <entry><type>bigint</></entry>
+ <entry>Number of queries in this database that have been canceled due to
+ deadlocks</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <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.
+ </para>
+
<table id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
<title><structname>pg_stat_all_tables</structname> View</title>
<tgroup cols="3">
***************
*** 1445,1634 **** postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
controls exactly which functions are tracked.
</para>
- <table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
- <title><structname>pg_stat_replication</structname> View</title>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Column</entry>
- <entry>Type</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><structfield>pid</></entry>
- <entry><type>integer</></entry>
- <entry>Process ID of a WAL sender process</entry>
- </row>
- <row>
- <entry><structfield>usesysid</></entry>
- <entry><type>oid</></entry>
- <entry>OID of the user logged into this WAL sender process</entry>
- </row>
- <row>
- <entry><structfield>usename</></entry>
- <entry><type>name</></entry>
- <entry>Name of the user logged into this WAL sender process</entry>
- </row>
- <row>
- <entry><structfield>application_name</></entry>
- <entry><type>text</></entry>
- <entry>Name of the application that is connected
- to this WAL sender</entry>
- </row>
- <row>
- <entry><structfield>client_addr</></entry>
- <entry><type>inet</></entry>
- <entry>IP address of the client connected to this WAL sender.
- If this field is null, it indicates that the client is
- connected via a Unix socket on the server machine.
- </entry>
- </row>
- <row>
- <entry><structfield>client_hostname</></entry>
- <entry><type>text</></entry>
- <entry>Host name of the connected client, as reported by a
- reverse DNS lookup of <structfield>client_addr</>. This field will
- only be non-null for IP connections, and only when <xref
- linkend="guc-log-hostname"> is enabled.
- </entry>
- </row>
- <row>
- <entry><structfield>client_port</></entry>
- <entry><type>integer</></entry>
- <entry>TCP port number that the client is using for communication
- with this WAL sender, or <literal>-1</> if a Unix socket is used
- </entry>
- </row>
- <row>
- <entry><structfield>backend_start</></entry>
- <entry><type>timestamp with time zone</></entry>
- <entry>Time when this process was started, i.e., when the
- client connected to this WAL sender
- </entry>
- </row>
- <row>
- <entry><structfield>backend_xmin</structfield></entry>
- <entry><type>xid</type></entry>
- <entry>This standby's <literal>xmin</> horizon reported
- by <xref linkend="guc-hot-standby-feedback">.</entry>
- </row>
- <row>
- <entry><structfield>state</></entry>
- <entry><type>text</></entry>
- <entry>Current WAL sender state</entry>
- </row>
- <row>
- <entry><structfield>sent_location</></entry>
- <entry><type>pg_lsn</></entry>
- <entry>Last transaction log position sent on this connection</entry>
- </row>
- <row>
- <entry><structfield>write_location</></entry>
- <entry><type>pg_lsn</></entry>
- <entry>Last transaction log position written to disk by this standby
- server</entry>
- </row>
- <row>
- <entry><structfield>flush_location</></entry>
- <entry><type>pg_lsn</></entry>
- <entry>Last transaction log position flushed to disk by this standby
- server</entry>
- </row>
- <row>
- <entry><structfield>replay_location</></entry>
- <entry><type>pg_lsn</></entry>
- <entry>Last transaction log position replayed into the database on this
- standby server</entry>
- </row>
- <row>
- <entry><structfield>sync_priority</></entry>
- <entry><type>integer</></entry>
- <entry>Priority of this standby server for being chosen as the
- synchronous standby</entry>
- </row>
- <row>
- <entry><structfield>sync_state</></entry>
- <entry><type>text</></entry>
- <entry>Synchronous state of this standby server</entry>
- </row>
- </tbody>
- </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>
-
- <table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
- <title><structname>pg_stat_database_conflicts</structname> View</title>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Column</entry>
- <entry>Type</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><structfield>datid</></entry>
- <entry><type>oid</></entry>
- <entry>OID of a database</entry>
- </row>
- <row>
- <entry><structfield>datname</></entry>
- <entry><type>name</></entry>
- <entry>Name of this database</entry>
- </row>
- <row>
- <entry><structfield>confl_tablespace</></entry>
- <entry><type>bigint</></entry>
- <entry>Number of queries in this database that have been canceled due to
- dropped tablespaces</entry>
- </row>
- <row>
- <entry><structfield>confl_lock</></entry>
- <entry><type>bigint</></entry>
- <entry>Number of queries in this database that have been canceled due to
- lock timeouts</entry>
- </row>
- <row>
- <entry><structfield>confl_snapshot</></entry>
- <entry><type>bigint</></entry>
- <entry>Number of queries in this database that have been canceled due to
- old snapshots</entry>
- </row>
- <row>
- <entry><structfield>confl_bufferpin</></entry>
- <entry><type>bigint</></entry>
- <entry>Number of queries in this database that have been canceled due to
- pinned buffers</entry>
- </row>
- <row>
- <entry><structfield>confl_deadlock</></entry>
- <entry><type>bigint</></entry>
- <entry>Number of queries in this database that have been canceled due to
- deadlocks</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <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.
- </para>
-
</sect2>
<sect2 id="monitoring-stats-functions">
--- 1651,1656 ----
On Sun, Nov 9, 2014 at 3:46 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 11/6/14 6:16 AM, Magnus Hagander wrote:
Another thought I had in that case is maybe we need to break out the
pg_stat_activity and pg_stat_replication views into their own table.
They are really the only two views that are different in a lot of
ways. Maybe call the splits "session statistics views" and "object
statistics views", instead of just "standard statistics views"? The
difference being that they show snapshots of *right now*, whereas all
the other views show accumulated statistics over time.Yeah, splitting this up a bit would help, too.
Here's an initial run of this. It still feels wrong that we have the
dynamic views under "the statistics collector". Perhaps longterm we
should look at actually splitting them out to a completely different
sect1?I only fixed the obvious parts in this - the split out, and the moving
of pg_stat_database_conflicts. But it's a first step at least.Objections?
Hearing no objections, I've pushed this. There's more to do, but it's a start.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers