Hi Thomas, On Tue, Sep 23, 2014 at 3:54 PM, Thomas Mueller <muel...@adobe.com> wrote: > Index plans need to be wrapped as well. If there is only one sub-index, > then it's easy: just wrap the plans from the sub-index. If there are > multiple sub-indexes, then most likely each sub-index will only return one > plan. If one of them returns multiple plans (which could be the case for > sorting), then all possible combinations could be wrapped and returned. If > there are too many combinations, then a warning could be logged and only a > subset of the combinations returned. If that really happens, we can still > think about a better solution (for example use a greedy algorithm as this > is done for join ordering). But personally, I don't think such a reduction > will ever be needed.
Not sure if we have to do all that at all. As the baseIndex is not registered with Oak going for such finer cost calculation is probably not required. We can just propagate the baseIndex plans I have updated a patch to OAK-2119 which changes AggregateIndex to implement AdvanceQueryIndex. With those changes (and related changes in Lucene) all test pass fine. If it looks fine I can go ahead with my change and move forward in OAK-2005. Note that initial plan was to 1. Have current LuceneIndex moved to AdvanceQueryIndex 2. Then branch off the impl and make a new copy which has changes done for Property index support Chetan Mehrotra
