Sami Imseih <samimseih@gmail.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
