Vikas Saurabh commented on OAK-937:

While I like the idea of providing tag-based-index hints (with a minor 
improvement could be pick a set of tags - "option(index tag <x>,<y>") );  but
bq. The main problem I want to address with this issue is: there are multiple 
Lucene index configurations, with different aggregation rules.
I think this particular problem might be solved by doing indirection inside 
index def itself. e.g.
+ <index>/aggregates/<type>/
   + useCase1/
      - oak:aggregateClassifier = true
      + <aggregateRuleTree1>
   + useCase2/
      - oak:aggregateClassifier = true
      + <aggregateRuleTree2>
   + <defaultAggregateRules>
... and extend {{contains()}} clause to potentially choose nothing (all 
aggregates participate) or a subset of classifiers.

The reason I'd want to solve multiple use-cases of aggregation/nodeScopeIndex 
this way is to still hold the convention that we have one index for a 
particular type - that, imo, makes people think more about index design and 
also provides a clearer view right away from index definitions (yes, tag 
approach would also work... but to me humans are worse at indirection than 

> Query engine index selection tweaks: shortcut and hint
> ------------------------------------------------------
>                 Key: OAK-937
>                 URL: https://issues.apache.org/jira/browse/OAK-937
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: query
>            Reporter: Alex Deparvu
>            Assignee: Thomas Mueller
>            Priority: Critical
>              Labels: performance
>             Fix For: 1.8
> This issue covers 2 different changes related to the way the QueryEngine 
> selects a query index:
>  Firstly there could be a way to end the index selection process early via a 
> known constant value: if an index returns a known value token (like -1000) 
> then the query engine would effectively stop iterating through the existing 
> index impls and use that index directly.
>  Secondly it would be nice to be able to specify a desired index (if one is 
> known to perform better) thus skipping the existing selection mechanism (cost 
> calculation and comparison). This could be done via certain query hints [0].
> [0] http://en.wikipedia.org/wiki/Hint_(SQL)

This message was sent by Atlassian JIRA

Reply via email to