Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff
От | Tom Lane |
---|---|
Тема | Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff |
Дата | |
Msg-id | 2883.1274062246@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > I believe this is a result of a limitation we've discussed > previously, namely, that the planner presently uses a limited, > special-case kludge to consider partial index scans, and the executor > uses another kludge to execute them. Yeah. To restore this case to something like what previous versions did, we need to be able to push an inner-indexscan parameter down through multiple join levels, which neither the planner nor executor can deal with at the moment. I am planning to work on this for 9.1. It may be worth pointing out that while the current code sucks for the case where a nestloop-with-inner-indexscan would be the best plan, the previous code sucked for every other case; because the previous code was only capable of generating the equivalent of a nestloop join. We have to continue down this path in order to get to the place we need to be. It's too bad that all the work didn't get done in one development cycle, but sometimes life's like that. regards, tom lane
В списке pgsql-hackers по дате отправления: