You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Joel Richard <jo...@adobe.com> on 2015/08/14 16:06:19 UTC

Patch for OAK-2679 to reduce query execution plan overhead

Hi,

I have created a patch for "OAK-2679 - Query engine: cache execution plans" [0] and attached it to the issue [1]. Before implementing the current approach with the minimum costs (more about this later), I have tried to cache the execution plan and later the index plans/costs. This failed because of various reasons:

- The UUIDDiffIndex can return completely different costs for the exact same query since/filter it takes the pending changes into consideration.
- Some indexes return costs based on the values which are used in the query and would require to use the whole filter object as a caching key. This wouldn’t make much sense because then the cache would fill and overflow quickly. Theoretically, this could be solved by using only the inputs which are necessary to calculate the cost, but this would require to iterate over the indexes and make the calculation of the cache key very expensive.

After discussing these problems with Thomas, we have decided to persue another approach which does not cache the costs/plans, but reduces the overhead of the execution plan calculation. The main idea is to assign each index a minimum cost and test the indexes in this order. Once an index is found and it's cost is smaller than the minimum cost of the next index, it can stop looking for a better index.

Furthermore, I have also introduced a negative cache for the ordered property and Solr index and improved the getCost for the property index.

One thing which probably has to be improved are the minimum cost constants. I have tried to use values based on the getCost caclulation, but since I am not very familar with the code and in case of the lucene indexes there aren't any calculations in the code, some of the chosen values are probably not ideal.

I have tested the performance with three different pages and the overhead for getBestSelectorExecutionPlan has been reduced from a) 21% to 4% b) 7.7% to 2.5% and c) 9.1% to 2.4% of the rendering time.

Please review the patch and let me know what you think about it.

Regards, Joel

[0] https://issues.apache.org/jira/browse/OAK-2679
[1] https://issues.apache.org/jira/secure/attachment/12750518/0001-OAK-2679-Reduce-execution-plan-overhead.patch