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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION
Дата
Msg-id 23156.1038926116@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION  ("Frank van Vugt" <ftm.van.vugt@foxi.nl>)
Ответы Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION
Список 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 по дате отправления:

Предыдущее
От: Nikk Anderson
Дата:
Сообщение: Re: Is there any limitations
Следующее
От: Frank van Vugt
Дата:
Сообщение: Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION