| От | Tom Lane |
|---|---|
| Тема | Re: BUG #4934: regression in IN with joins in subselect |
| Дата | |
| Msg-id | 5972.1248309287@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #4934: regression in IN with joins in subselect (Benjamin Reed <ranger@opennms.org>) |
| Список | pgsql-bugs |
Benjamin Reed <ranger@opennms.org> writes:
> Attached is a test case, including the query that causes the error at
> the end. On 8.3, it returns 1 row (192.168.1.1), on 8.4 including the
> git 8.4 branch, it returns none.
Thanks, it seems like the problem is that it's applying *both* its
methods for implementing an IN join: it's unique-ifying the sub-select
output via a HashAggregate, and then using a Semi Join anyway when that
gets joined to the "node" table. And the Semi Join has indeterminate
output for some of the other output columns. (The join order it's
choosing seems a bit odd too, but with so few rows in the tables it may
be that all the join orders seem to have the same cost.) I think this
is probably a small fix, but running out of energy for tonight ...
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера