Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION

"Frank van Vugt" <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> Since the left side of the join clause is composed out of three concatenated
> text-parts resulting in one single piece of type text, I'd expect the
> planner to avoid the nested loop.

Probably not, since the first thing it does is to flatten the
sub-select, leaving it with a concatenation expression in the
WHERE-clause. (I was too sleepy last night to realize that you
were comparing a concatenation to old_id, rather than making two
separate comparisons :-()

We really need to fix the planner to be able to do merge/hash on
"arbitrary expression = arbitrary expression", not only "Var = Var".
IIRC, this is doable in principle, but there are a few routines that
would need to be improved.

regards, tom lane