On Tue, Nov 16, 2010 at 2:53 PM, Greg Stark <st...@mit.edu> wrote: >> Yeah, VERBOSE is kind of a catch-all for things that we don't have >> individual flags for. But I think it's better for each piece of data >> to depend on one setting, rather than a combination of two or more >> settings. Otherwise you end up being forced to use VERBOSE and then >> you get this deluge of output. I'd actually sort of like to remove >> some things from VERBOSE and give them their own settings, rather than >> adding more. The fact that VERBOSE turns on "Output:" is particularly >> annoying. > > I tend to think it's "don't be clever about showing me just the useful > stuff, include whatever you've got even if you think it's not useful". > I would consider it a bug if there's anything that requires VERBOSE > and a user finds is relevant to a fixing a user problem (as opposed to > debugging a postgres bug). > > I'm concerned about the converse problem. The "I why do I have to > include two dozen flags to get postgres to actually include > everything?". Along with the "try turning on this flag and resending > the plan. Hm, oops forgot a flag resend it again with this too. Oh > that's still not including something we need try it a third time with > this flag" etc.
Well, the reason's pretty obvious in this case: each of ANALYZE, BUFFERS, and RESOURCE adds a huge amount of incremental overhead. I wouldn't object to having a flag that says "just turn on absolutely everything you've got". Then you could just say: EXPLAIN (THECRAPOUTOFIT) query... In any case, this seems like an argument for making RESOURCE print everything we think might ever be useful, rather than just some subset of it. A rule that says "print some of the RESOURCE information when RESOURCE is specified but the rest only if VERBOSE is also specified or if a non-text output format is used" seems to have exactly the sort of ickiness you're complaining about; I'd rather make it all or nothing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
