[
https://issues.apache.org/jira/browse/OAK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595953#comment-15595953
]
Alexander Klimetschek edited comment on OAK-4887 at 10/21/16 6:35 PM:
----------------------------------------------------------------------
h4. 2 indexes to test index selection
Note that in the above case there is only one index that would apply.
Now I tried to add another index named {{damAssetLuceneCreated}} that would
include the {{jcr:created}} property, to see if it would get preferred over the
existing index {{damAssetLucene}}. I basically copied the index, and added
jcr:created as property in the indexRules.
However, now it only ever considers the new index - the other one is never
included in the index cost list anymore:
{noformat}
//element(*, dam:Asset) order by @jcr:created
{noformat}
{noformat}
cost using filter Filter(query=select [jcr:path], [jcr:score], * from
[dam:Asset] as a order by [jcr:created] /* xpath: //element(*, dam:Asset) order
by @jcr:created */, path=*)
cost for reference is Infinity
cost for property is Infinity
cost for nodeType is Infinity
cost for lucene-property[/oak:index/damAssetLuceneCreated] is 464.0
cost for aggregate lucene is Infinity
cost for solr is Infinity
cost for traverse is 226100.0
{noformat}
h4. 2 indexes with created vs. modified
Then I also removed the indexing of the {{jcr:lastModified}} property from the
new index ({{damAssetLuceneCreated}}), reindexed both, and then ran this query:
{noformat}
//element(*, dam:Asset) order by @jcr:lastModified
{noformat}
This will still pick the newer {{damAssetLuceneCreated}} index, although it
does not index the jcr:lastModified property and there is a better index with
{{damAssetLucene}} that does index it.
{noformat}
cost using filter Filter(query=select [jcr:path], [jcr:score], * from
[dam:Asset] as a order by [jcr:lastModified] /* xpath: //element(*, dam:Asset)
order by @jcr:lastModified */, path=*)
cost for reference is Infinity
cost for property is Infinity
cost for nodeType is Infinity
cost for lucene-property[/oak:index/damAssetLuceneCreated] is 464.0
cost for aggregate lucene is Infinity
cost for solr is Infinity
cost for traverse is 226100.0
{noformat}
I would expect it to pick the optimal index {{damAssetLucene}}.
was (Author: alexander.klimetschek):
h4. 2 indexes to test index selection
Note that in the above case there is only one index.
Now I tried to add another index named {{damAssetLuceneCreated}} that would
include the {{jcr:created}} property, to see if it would get preferred over the
existing index {{damAssetLucene}}. I basically copied the index, and added
jcr:created as property in the indexRules.
However, now it only ever considers the new index - the other one is never
included in the index cost list anymore:
{noformat}
//element(*, dam:Asset) order by @jcr:created
{noformat}
{noformat}
cost using filter Filter(query=select [jcr:path], [jcr:score], * from
[dam:Asset] as a order by [jcr:created] /* xpath: //element(*, dam:Asset) order
by @jcr:created */, path=*)
cost for reference is Infinity
cost for property is Infinity
cost for nodeType is Infinity
cost for lucene-property[/oak:index/damAssetLuceneCreated] is 464.0
cost for aggregate lucene is Infinity
cost for solr is Infinity
cost for traverse is 226100.0
{noformat}
h4. 2 indexes with created vs. modified
Then I also removed the indexing of the {{jcr:lastModified}} property from the
new index ({{damAssetLuceneCreated}}), reindexed both, and then ran this query:
{noformat}
//element(*, dam:Asset) order by @jcr:lastModified
{noformat}
This will still pick the newer {{damAssetLuceneCreated}} index, although it
does not index the jcr:lastModified property and there is a better index with
{{damAssetLucene}} that does index it.
{noformat}
cost using filter Filter(query=select [jcr:path], [jcr:score], * from
[dam:Asset] as a order by [jcr:lastModified] /* xpath: //element(*, dam:Asset)
order by @jcr:lastModified */, path=*)
cost for reference is Infinity
cost for property is Infinity
cost for nodeType is Infinity
cost for lucene-property[/oak:index/damAssetLuceneCreated] is 464.0
cost for aggregate lucene is Infinity
cost for solr is Infinity
cost for traverse is 226100.0
{noformat}
I would expect it to pick the optimal index {{damAssetLucene}}.
> Query cost estimation: ordering by an unindexed property not reflected
> ----------------------------------------------------------------------
>
> Key: OAK-4887
> URL: https://issues.apache.org/jira/browse/OAK-4887
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 1.4.2
> Reporter: Alexander Klimetschek
> Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> A query that orders by an unindexed property seems to have no effect on the
> cost estimation, compared to the same query without the order by, although it
> has a big impact on the execution performance for larger results/indexes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
