Look into nested query performance regressions

[jpountz]

While the query changes that we did in 2.0+ improved the situation for queries that have slow verifications (phrase, script) or filters that are not reused (by making sure they are reused before caching), it seems that it also made other queries slower eg. the nested query.

Things might already be partially fixed in 5.0+ thanks to changes like https://issues.apache.org/jira/browse/LUCENE-7330 .

[jpountz]

It's been a long time since I opened this issue but some progress has been made:

• Do not cache term queries. #21566 should help the query cache cache more stuff. This is important in the context of nested queries because nested mappings make Elasticsearch add a filter to every query that makes sure it cannot match nested docs.
• https://issues.apache.org/jira/browse/LUCENE-7654 makes nested queries compute scores lazily, which should make them faster when used in conjunctions. It also makes ToParentBlockJoinQuery implement the new scorerProvider API, which means it will play well with IndexOrDocValuesQuery (https://issues.apache.org/jira/browse/LUCENE-7643).

I think there is at least one other thing to look into: the implicit filters that we add because of nested mappings. For instance if you run a nested query, we will implicily add both a filter on the child query in order to make sure it may only match documents from the child space, and on the top-level query in order to make sure it may only match documents from the parent space. This makes queries more complex and thus slower to execute, and also has some bad side-effects like polluting the query cache.

[jpountz]

Based on changes coming to 5.4 and how they perform in the new Nested track (https://elasticsearch-benchmarks.elastic.co/nested/index.html), I consider this issue fixed.