[
https://issues.apache.org/jira/browse/OAK-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120750#comment-16120750
]
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.
{noformat}
+ <index>/aggregates/<type>/
+ useCase1/
- oak:aggregateClassifier = true
+ <aggregateRuleTree1>
+ useCase2/
- oak:aggregateClassifier = true
+ <aggregateRuleTree2>
+ <defaultAggregateRules>
{noformat}
... 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
computers)
> 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
(v6.4.14#64029)
