Re: Terrible plan for join to nested union

Поиск
Список
Период
Сортировка
От Nate Allan
Тема Re: Terrible plan for join to nested union
Дата
Msg-id 9B2D6747F4AB8A47BE45216B06DEDAF92ABE6791@PREXMB01.myfamily.int
обсуждение исходный текст
Ответ на Re: Terrible plan for join to nested union  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
>Right now, UNION DISTINCT, along with INTERSECT and EXCEPT, have basically no optimization support whatsoever...
> Sorry to be the bearer of bad news, but this isn't going to change just because you try to label it a bug.

Given the medium, I'll try not to read that in a snarky tone, after all, surely it's not unreasonable to label it a
defectfor a system not to optimize one of the basic relational primitives.  That said, I know well the annoyance when a
usercries bug when the system is working as-designed.  In any case, I'm at least glad to have resolution; I know that
thereis no choice but to work around it. 

For a maximally general work-around given that the union is the essence of a reused view, perhaps a reasonable approach
isto switch to Union All and nest it within a Distinct outer query.  That seems to produce workable plans in my tests
sofar.  Maybe that could even form the basis of a planner enhancement that wouldn't require a complete refactor. 

Thanks again,

-Nate



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Terrible plan for join to nested union
Следующее
От: Sylvain CAILLET
Дата:
Сообщение: Re: Create tables performance