Re: improve EXPLAIN for wide tables

Sami Imseih <samimseih(at)gmail(dot)com> writes:
>>> Looking further into this improvement, I started to question if it is
>>> necessary to make columns unique for EXPLAIN purposes?

>> Yes, otherwise references to them elsewhere in the plan will be
>> ambiguous.

> Explain will qualify the column name with the table name such as the simple
> example below with the experimental patch.

But if the column names are ambiguous within the same RTE, how does
table-qualification fix that? And it's within-the-same-RTE that
we're concerned with here.

> I have not been able to find cases,
> except for the failed test case that involves "?column?", in which the
> plan will result in ambiguous column names.

It only takes one case to mean we have to deal with it ;-). But I'm
fairly sure that there are many other cases, since the parser doesn't
restrict the output names of a sub-SELECT to be unique.

>> Is there any reason to think that 52c707483 wasn't a sufficient
>> response to this issue?

> In the case reported, similar to the one in the earlier attached
> experiment.sql, even with the hash table optimization, there is still
> significant
> overhead from the unique-ifying work. for such users, this can impact real-world
> performance particularly if they have enabled extensions such as auto_explain.

This detail-free claim doesn't persuade me that we have to do
something more. (And I'm not buying the idea that people
should expect auto_explain to be free, anyway.)

regards, tom lane