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 188.8.131.52. 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/ -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers