jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Richard (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-2679) Query engine: cache execution plans
Date Fri, 14 Aug 2015 14:01:45 GMT

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

Joel Richard updated OAK-2679:
    Attachment: 0001-OAK-2679-Reduce-execution-plan-overhead.patch

Attached patch (0001-OAK-2679-Reduce-execution-plan-overhead.patch) which does not use a cache,
but instead reduces the execution plan overhead with the following changes:

* Add QueryIndex.getMinimalCost which allows to skip the remaining index cost comparison if
it finds an index whose cost is <= the minimum cost of the next more expensive index
* Implement getMinimalCost for all indexes
* Do not read index definitions in PropertyIndex.getCost if the filter does not have property
restrictions and selector restrictions
* Stop looking for better index definition in PropertyIndex once it finds a definition with
the absolute minimum cost
* Cache for 30 seconds if there are no ordered property or Solr indexes

More about it on the mailing list in a minute.

> Query engine: cache execution plans
> -----------------------------------
>                 Key: OAK-2679
>                 URL: https://issues.apache.org/jira/browse/OAK-2679
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, query
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>              Labels: performance
>             Fix For: 1.3.5
>         Attachments: 0001-OAK-2679-Reduce-execution-plan-overhead.patch, OAK-2679.patch,
> If there are many indexes, preparing a query can take a long time, in relation to executing
the query.
> The query execution plans can be cached. The cache should be invalidated if there are
new indexes, or indexes are changed; a simple solution might be to use a timeout, and / or
a manual cache clean via JMX or so.

This message was sent by Atlassian JIRA

View raw message