On Mon, Feb 27, 2012 at 14:36, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> The problem with a separate column is that it makes the table very
>> wide (some of those functions have very long name).
>
> Yeah, that's one thing I don't like about what you actually did,
> either - it made some of the tables much wider.
Uh, can you give me an example of one? While they will all become
wider if you actually need to, I don't see any of those tables as wide
enough to cause any trouble that automatic linebreaks don't fix?
>>> 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.
>>
>> That one would at least work. You mean basically:
>>
>> |pg_stat_database.xact_commit|pg_stat_get_db_xact_commit|
>> |pg_stat_database.xact_rollback|pg_stat_get_db_xact_rollback|
>>
>> etc etc for each column/function, right?
>
> Yeah.
Ok, I'll see if I can put something like that together and see what it
looks like. Unless somebody else objects to that way?
>>> Also, I wonder if we should promote section 27.2.2.1. Other Statistics
>>> Functions to 27.2.3.
>>
>> I was considering that, but given that 27.2.2 is "viewing statistics",
>> it does seem like a sub-section to that.. Though maybe if we make the
>> lis tof views into their own section *as well*, so we have one sectoin
>> for "how to view it", one for "views" and one for "other functions" it
>> would make more sense.
>
> My thought was that a good half of those "other statistics functions"
> don't have all that much to do with viewing anything, so the logical
> argument for that section to need to be under "viewing statistics"
> seems a bit weak.
True.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/