Re: pgstat documentation tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgstat documentation tables
Date: 2012-02-27 03:44:32
Message-ID: CA+TgmoYp_2naD6ff6q3MxAeGmx1ea_YjhVwb8qsw+aDZNsN=9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 25, 2012 at 9:33 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Jan 16, 2012 at 02:03, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> On 01/15/2012 12:20 PM, Tom Lane wrote:
>>>
>>> Please follow the style already used for system catalogs; ie I think
>>> there should be a summary table with one entry per view, and then a
>>> separate description and table-of-columns for each view.
>>
>>
>> Yes, that's a perfect precedent.  I think the easiest path forward here is
>> to tweak the updated pg_stat_activity documentation, since that's being
>> refactoring first anyway.  That can be reformatted until it looks just like
>> the system catalog documentation.  And then once that's done, the rest of
>> them can be converted over to follow the same style.  I'd be willing to work
>> on doing that in a way that improves what is documented, too.  The
>> difficulty of working with the existing tables has been the deterrent for
>> improving that section to me.
>
> I've applied a patch that does this now. Hopefully, I didn't create
> too many spelling errors or such :-)
>
> I also applied a separate patch that folded the list of functions into
> the list of views, since that's where they are called, as a way to
> reduce duplicate documentation. I did it as a spearate patch to make
> it easier to back out if people think that was a bad idea...

I think it's a little awkward this way; maybe it would be better as a
separate table column. Or maybe it was better the way it was; I'm not
sure. Or maybe we could have a separate table that just gives the
equivalences between stats table-column pairs and functions. Of those
ideas, I think I like "separate table in the same column" the best.

Also, I wonder if we should promote section 27.2.2.1. Other Statistics
Functions to 27.2.3.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-27 04:59:11 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous Message Tom Lane 2012-02-27 03:37:39 Re: Memory usage during sorting