Prev: pg_upgrade and extra_float_digits
Next: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
From: Andres Freund on 16 May 2010 22:40
On Monday 17 May 2010 04:10:46 Tom Lane wrote:
> Robert Haas <robertmhaas(a)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.
> 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.
Yes, I realize that. Thats why I didnt report it as an actual bug... And its
way easier to deal with 8.4s "deficiency" than with the former behaviour.

Thanks,

Andres

PS: I think it lead me to an actual bug, expect a report tomorrow...

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: pg_upgrade and extra_float_digits
Next: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle