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 по дате отправления: