> I wrote:
> > Sami Imseih writes:
> >> I am attaching a patch that deals with the RTE_JOIN case.
>
> > I'll take a look. Thanks for the test demonstrating that
> > this makes a visible performance difference.
>
> Pushed with some simplification: we don't need a new flag,
> because none of the ca
I wrote:
> Sami Imseih writes:
>> I am attaching a patch that deals with the RTE_JOIN case.
> I'll take a look. Thanks for the test demonstrating that
> this makes a visible performance difference.
Pushed with some simplification: we don't need a new flag,
because none of the callers of set_sim
Sami Imseih writes:
>> 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.
> good point. I see the error in my original line of thinking now.
> In f
> 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
> 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 parse
I had a thought about this: I don't think EXPLAIN is ever required
to print the names of join alias variables (since the planner flattens
all join alias variables to some kind of expression over their
underlying columns). So we could skip assigning column names to
join RTEs at all, if we know that
Sami Imseih 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 suc
> > 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 b
Sami Imseih 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.
It looks like your proposal tries to dodge that by unique-ifying
in some
Recently, a user reported that running an explain for a query joining
many wide tables taking more than 1 minute to complete. Running the
query without explain takes only a few seconds.
Further research showed that this is similar to a report from
2018 [1]. colname_is_unique is used to assign uniq
