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

Reply via email to