On Mon, Feb 27, 2012 at 14:36, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander <mag...@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 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.


 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:

Reply via email to