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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance problem in textanycat/anytextcat
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Keepalive for max_standby_delay