Re: [HACKERS] Order of views in stats docs

2014-11-16 Thread Magnus Hagander
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

2014-11-09 Thread Magnus Hagander
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

2014-11-06 Thread Magnus Hagander
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

2014-11-06 Thread Peter Eisentraut
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

2014-11-05 Thread Magnus Hagander
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

2014-11-05 Thread Tom Lane
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

2014-11-05 Thread Peter Eisentraut
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

2014-11-05 Thread Jim Nasby

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