Hi, Index aggregation is only needed for full-text queries. So I think it's better to not use use, change, or wrap the AggregateIndex right now. This also has the advantage that we don't accidentally break anything.
Later on, when we have time to change AggregateIndex to implement AdvanceQueryIndex: > AggregateIndex aggregates the cost also. How such thing should be >implemented in terms of IndexPlan is not clear. 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. > Further I do not understand the AggregateIndex logic very well and not >sure how a Fulltext index which also handles property restriction can be >wrapped. Any guidance here would be helpful! Well, it sounds like we need to improve the documentation. That's better than explaining by email... >1. Have two impls LuceneIndex and LucenePropertyIndex I would actually prefer that, as it reduces the risk. >With this existing logic would not be modified and we can move ahead >with Lucene based property index. Later once we unify them we can >tackle this issue Yes, I think that would be good. Regards, Thomas
