On 09/11/2015 15:48, Michael Marth wrote: > Hi, > > Afaiu your proposal would mix 2 different concerns: a) the query plan, which > should be guided by the cost to execute a query and b) how up-to-date an > index is. > I do not see why b) should interfere with a) unless you have a situation > where an async index is so far behind that it should not be used at all. > > From your original mail: > > Sometimes we could have the same query better served by a property > index, or traversing for example. > > Could you please specify “better” in the proposal above? > We have situations where the async index is lagging behind. Quite a lot. Somewhere like 7 minutes or more.
While I appreciate the fact that it should not happens and we're working towards that, we could think of a better way to deal with the situation in a "reactive" manner. By design a query *could* be served by more than one index. Let's say from a PropertyIndex and a Lucene one for example. In normal situation the cost from a lucene index would be lower as it better fits the query. However if the index lags behind it plays but instead returns a wrong resultset as it doesn't have yet all the latest information. In this case, in my opinion, it would be better to serve the query off a property index, even if slightly slower but up to date. Hence my idea of having lucene "auto-tuning" based on how up to date it is. Please note that if there are no other suitable indexes the lucene one will be the winning one. Still I don't know whether that would even be possible. Didn't look at the details yet. Davide
