Re: join_references: variable not in subplan target lists
От | Tom Lane |
---|---|
Тема | Re: join_references: variable not in subplan target lists |
Дата | |
Msg-id | 7039.1056901341@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: join_references: variable not in subplan target lists (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I said: > While I now need to burrow into the IN-as-join code and find out where > it's dropping the ball, I don't think this need stop you from making > progress on the information schema. The reason the problem is appearing > seems to be the implied cast that's getting introduced in the IN > comparison, This theory turns out to be mistaken, or at least only marginally relevant; it's possible to make the problem happen with no casts at all. I think the reason that adding or removing a cast made the problem appear/disappear for me was just that it changed which plan got selected (since the estimation routines are not very bright about coping with joins on expressions). The failure occurs when the planner chooses to implement an IN by unique-ifying the result of the sub-select and then using that as the outer side of a join. If that join is not the topmost join of the whole plan, we fail --- because the unique-ified plan node only emits the variables that are supposed to be used in the IN comparison, but the upper join generates a targetlist that includes every variable used anywhere in the query. If you hit the problem again, you might find that turning off enable_hashagg lets you make progress. A real solution seems to require some honest accounting for which variables need to appear in join targetlists and which don't; I'm off to look at that now ... regards, tom lane
В списке pgsql-hackers по дате отправления: