Hello, The main issue of delegating in entryCount, is that if the index contains more than 1000 docs and the query does not contain fulltext clauses the index planner will use the number *1000 *as the entryCount, ovewriting the actual size of the index [Math.min(definition.getEntryCount(), getReader(). *numDocs())*]. Nowadays the current indexes involved in the collision in our system, contain serveral million and a several thousand of documents respectively. The cost, for both indexes performing most common queries is *1001, *yes* 1001* = costPerExecution + (costPerEntry * entryCount) = 1 + (1*1000). Thereby we can't predict which index will be used.
Regards. On Wed, May 17, 2017 at 9:40 AM, Chetan Mehrotra <[email protected]> wrote: > > Using the entryCount was our first option, but we decided to modify > > costPerEntry instead. Basically these are the reasons: > > What I meant was not the use of "entryCount" property but just that > the sub index /nodeA/nodeB/includedC being a subset of /nodeA/nodeB/ > it would have lower value for numDocs and hence any query having path > restriction of /nodeA/nodeB/includedC would get to use that index (by > virtue of numDocs being less than parent). So you would not need to do > any tweaking > > > response we expect. It seems that in OAK, indexes are used to speed up > > queries, but not as a complete information entity that must answer every > > query clause. Well, I'm still figuring out the big picture of querying > > Yes the index may only be partially covering the query. So index job > is to provide a super set of possible result paths and Query Engine > would then evaluate the restriction for each path and at the > repository state per current JCR Session (except fulltext constraints) > > Chetan Mehrotra >
