>> To be clear, I'd love to have this feature. But if there is a choice
>> between reducing planning time significantly for everyone and NOT
>> getting this feature, and increasing planning time significantly for
>> everyone and getting this feature, I think we will make more people
>> happy by doing the first one.
>
> We're not really talking about "are we going to accept or reject a
> specific feature". We're talking about whether we're going to decide
> that the last two years worth of planner development were headed in
> the wrong direction and we're now going to reject that and try to
> think of some entirely new concept. This isn't an isolated patch,
> it's the necessary next step in a multi-year development plan. The
> fact that it's a bit slower at the moment just means there's still
> work to do.
>
Those planner improvements are very promising despite the current
extra cost in planning in some situations. And it looks like a good
solution to have an effective and interesting index-only usage.
We've hitten the planner limits and a lower level of the planner need
to be revisited. Please Tom, keep on.
And it might be that 9.2 is a very good release to do that because if
there is performance impact from this patch (at the end), there are so
many improvment in other places that it should be easely compensated
for users. It might be harder to do the change in 9.3 if the
performance of 9.3 are lower than the ones from 9.2.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation