Re: full outer join performance

Поиск
Список
Период
Сортировка
От Ben
Тема Re: full outer join performance
Дата
Msg-id 43272AC1.5030109@silentmedia.com
обсуждение исходный текст
Ответ на Re: full outer join performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Tom Lane wrote:

>I think the problem was that he had
>
>    select ... from a, b full join c on ... where ...
>
>where table b is big and you only need a few rows from it, so it really
>needs to be joined last, but the above forced doing it first.  It wasn't
>clear to me why he wanted the full join at all (in fact, you could see
>from the plan that the planner had been able to reduce it to a left join
>because there were WHERE clauses that'd discard one set of null-extended
>rows anyway).  Without knowing that, it's hard to say whether there's
>another way to get what he wants.
>
>
>
Without the outer join, the output was missing the joined rows from a
and b when there was no matching row in c. (Tables a and c both
referenced b.)

I suppose I could have used a left join instead of a full join, but
either way the results were much slower than an inner join, and I was
able to redo some other logic to let an inner join work just fine.

В списке pgsql-general по дате отправления:

Предыдущее
От: Karsten Hilbert
Дата:
Сообщение: GNUmed release 0.1 announcement
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: Using COPY command when input file contain backslashes?