Gregory Stark <[EMAIL PROTECTED]> writes: > EXPLAIN VERBOSE is indeed ridiculous.
There are other ways to get that printout, too, if you really do need it. > IMHO You could also move "width" to VERBOSE while you're at it. In fact you'll > probably want width in precisely the same cases where you want the target > list. I'm not convinced. The width is often useful to understand why the planner did something (eg, chose a hash plan or not). The exact contents of the targetlist are usually not nearly as interesting. > So +1 for just redefining VERBOSE. Barring other objections I'll go do that. BTW, while testing the code I already found a bug: regression=# set enable_hashagg to 0; SET regression=# explain select thousand from tenk1 group by 1; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------- Group (cost=1122.39..1172.39 rows=998 width=4) Output: thousand -> Sort (cost=1122.39..1147.39 rows=10000 width=4) Output: unique1, unique2, two, four, ten, twenty, hundred, thousand, twothousand, fivethous, tenthous, odd, even, stringu1, stringu2, string4 Sort Key: thousand -> Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=4) Output: unique1, unique2, two, four, ten, twenty, hundred, thousand, twothousand, fivethous, tenthous, odd, even, stringu1, stringu2, string4 (7 rows) Only the "thousand" column is needed, so why is it emitting all columns? It's evidently allowing the "use physical tlist" optimization to fire, which saves cycles inside the SeqScan node --- but in this context that's penny-wise and pound-foolish, because we're pumping useless data through the Sort. There is code in the planner that's supposed to notice the needs of the next level up, but it's not getting this case right for some reason... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers