Thread: EXPLAIN VERBOSE vs resjunk output columns

Currently, explain.c goes out of its way to not print "resjunk" output
columns (those not meant to be seen by the user, such as hidden sort key
columns) in EXPLAIN VERBOSE targetlists.  I made 8.4 act that way for
reasons I don't recall at the moment, but I've found several times now
that it's misleading.  Would anybody complain about including those
columns?

An example of what I'm talking about:

regression=# explain verbose select unique1 from tenk1 order by tenthous;                              QUERY PLAN
                       
 
------------------------------------------------------------------------Sort  (cost=1122.39..1147.39 rows=10000
width=8) Output: unique1  Sort Key: tenk1.tenthous  ->  Seq Scan on public.tenk1  (cost=0.00..458.00 rows=10000
width=8)       Output: unique1
 
(5 rows)

The seqscan is actually emitting both unique1 and tenthous, as it
obviously must or the sort node would have nothing to work with.
You can see that from the fact that the estimated row width is
8 bytes (two integers) ... but tenthous is nowhere to be seen in the
Output: line.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Currently, explain.c goes out of its way to not print "resjunk" output
> columns (those not meant to be seen by the user, such as hidden sort key
> columns) in EXPLAIN VERBOSE targetlists.  I made 8.4 act that way for
> reasons I don't recall at the moment, but I've found several times now
> that it's misleading.  Would anybody complain about including those
> columns?

+1 to include them.
Thanks,
    Stephen

On Sat, Aug 22, 2009 at 1:37 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> You can see that from the fact that the estimated row width is
> 8 bytes (two integers) ... but tenthous is nowhere to be seen in the
> Output: line.

+1 for self-consistent output. If we're including their size in
"width" then they should be in the output list. If there was some way
to mark the junk columns so users could tell which columns are being
used higher up and which aren't -- which might be helpful if there are
ambiguous names -- then that might be good. Nothing comes to mind
offhand that wouldn't just be a lot of clutter though.

-- 
greg
http://mit.edu/~gsstark/resume.pdf