Re: [HACKERS] Order of views in stats docs
On Sun, Nov 9, 2014 at 3:46 PM, Magnus Hagander mag...@hagander.net wrote: On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut pete...@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
Re: [HACKERS] Order of views in stats docs
On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut pete...@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/ *** 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 !productnamePostgreSQL/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 !productnamePostgreSQL/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 ! titleViewing 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 ! titleViewing 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 !titleStandard 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 !titleDynamic 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 + entrystructnamepg_stat_replication/indextermprimarypg_stat_replication/primary/indexterm/entry + entryOne 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 +titleCollected Statistics Views/title + +tgroup cols=2 + thead + row + entryView Name/entry + entryDescription/entry + /row +
Re: [HACKERS] Order of views in stats docs
On Wed, Nov 5, 2014 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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
Re: [HACKERS] Order of views in stats docs
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
[HACKERS] 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
Re: [HACKERS] Order of views in stats docs
Magnus Hagander mag...@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
Re: [HACKERS] Order of views in stats docs
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
Re: [HACKERS] Order of views in stats docs
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