Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff
Date
Msg-id 2883.1274062246@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Sort of a planner regression 8.3->8.4 (due to EXISTS inlining) and related stuff
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance problem in textanycat/anytextcat
Next
From: Fujii Masao
Date:
Subject: Re: Keepalive for max_standby_delay