Gregory Stark <stark@enterprisedb.com> 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
