On Fri, Jun 23, 2006 at 08:14:07PM +0300, Tzahi Fadida wrote:
> I guess i can make a map of attributes participating in an index
> of a relation.
> Also, i would have to take into account the type of index used.
> For example, a btree should have the capability to do prefix key
> searches while hash indices probably can't.
> Then check each target tuple if it can use an index.
> All this before constructing the query for the planner.
At the end of the day it comes down to that Postgres has no way
currently to express the plan you want, so we're not talking about
small planner or optimiser changes, we're talking about creating a
completely new node type which could be used for this purpose.
It would be a node that sat on top of a "seq scan" and had a number of
conditions. Each tuple would be matched against each condition. Once a
condition is matched, that tuple is returned. Once a condition has
matched N times it is disabled. Once all conditions are disabled,
you're done.
Seems terribly special purpose, yet I don't see how you could do it any
other way. If it wern't for the LIMIT clauses the whole operation would
be trivial.
> > It's conceivable that the planner could prove that neither effect is
> > possible in a particular query and then make the transformation
> > automatically, but I'm not about to expend that kind of planning effort
> > on such an odd case --- checking for it would waste entirely too many
> > cycles in most cases.
I think in the case we have here, the transformation wouldn't apply
anyway (otherwise it could be done by hand).
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
