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

From Tom Lane
Subject Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION
Date
Msg-id 23156.1038926116@sss.pgh.pa.us
Whole thread Raw
In response to Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION  ("Frank van Vugt" <ftm.van.vugt@foxi.nl>)
Responses Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION
List pgsql-performance
"Frank van Vugt" <ftm.van.vugt@foxi.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

pgsql-performance by date:

Previous
From: Nikk Anderson
Date:
Subject: Re: Is there any limitations
Next
From: Frank van Vugt
Date:
Subject: Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION