jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3722) Query: an index is used even where traversing is faster
Date Wed, 05 Feb 2014 11:08:09 GMT

     [ https://issues.apache.org/jira/browse/JCR-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Thomas Mueller updated JCR-3722:
--------------------------------

    Description: 
Currently, for queries that can use an index, the index is always preferred over traversing
over the nodes. For joins, sometimes is much faster to traverse, specially the exact path
is known. Example:

/jcr:root/testroot/b[@jcr:uuid]

This query will use the index on "jcr:uuid", and traverse over all nodes with the property
"jcr:uuid", even thought in fact only one node would need to be read when using the TraversingIndex.

The problems are: Currently, the TraversingIndex is not even asked to estimate the cost. Also,
the cost estimation of the TraversingIndex is incorrect for such cases. 

We will also need to verify and fix the cost estimation of the other indexes (for example
the PropertyIndex) conforms the QueryIndex API (getCost is supposed to return the estimated
number of entries to traverse).


  was:
Currently, for queries that can use an index, the index is always preferred over traversing
over the nodes. For joins, sometimes is much faster to traverse, specially the exact path
is known. Example:

{noformat}
/jcr:root/testroot/b[@jcr:uuid]
{noformat}

This query will use the index on "jcr:uuid", and traverse over all nodes with the property
"jcr:uuid", even thought in fact only one node would need to be read when using the TraversingIndex.

The problems are: Currently, the TraversingIndex is not even asked to estimate the cost. Also,
the cost estimation of the TraversingIndex is incorrect for such cases. 

We will also need to verify and fix the cost estimation of the other indexes (for example
the PropertyIndex) conforms the QueryIndex API (getCost is supposed to return the estimated
number of entries to traverse).



> Query: an index is used even where traversing is faster
> -------------------------------------------------------
>
>                 Key: JCR-3722
>                 URL: https://issues.apache.org/jira/browse/JCR-3722
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: query
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>
> Currently, for queries that can use an index, the index is always preferred over traversing
over the nodes. For joins, sometimes is much faster to traverse, specially the exact path
is known. Example:
> /jcr:root/testroot/b[@jcr:uuid]
> This query will use the index on "jcr:uuid", and traverse over all nodes with the property
"jcr:uuid", even thought in fact only one node would need to be read when using the TraversingIndex.
> The problems are: Currently, the TraversingIndex is not even asked to estimate the cost.
Also, the cost estimation of the TraversingIndex is incorrect for such cases. 
> We will also need to verify and fix the cost estimation of the other indexes (for example
the PropertyIndex) conforms the QueryIndex API (getCost is supposed to return the estimated
number of entries to traverse).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message