2014-09-23 13:31 GMT+02:00 Chetan Mehrotra <[email protected]>:
> Hi Thomas, > > On Tue, Sep 23, 2014 at 3:54 PM, Thomas Mueller <[email protected]> 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 > I don't have insights about the AggregateIndex however this plan still looks the most reasonable one. My 0.02 cents, Tommaso > > Chetan Mehrotra >
