Re: 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/

Magnus Hagander <magnus(at)hagander(dot)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

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.

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

On Wed, Nov 5, 2014 at 4:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)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/

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.

On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut <peter_e(at)gmx(dot)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/

On Sun, Nov 9, 2014 at 3:46 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut <peter_e(at)gmx(dot)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/