Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi level nested sorting incorrectly using bitset filter cache #31783

Closed
martijnvg opened this issue Jul 4, 2018 · 1 comment · Fixed by #32204
Closed

Multi level nested sorting incorrectly using bitset filter cache #31783

martijnvg opened this issue Jul 4, 2018 · 1 comment · Fixed by #32204
Assignees
Labels
>bug :Search/Search Search-related issues that do not fall into other categories

Comments

@martijnvg
Copy link
Member

While looking into #31554, I noticed that in case multi level nested sorting is used and levels use a nested filter then the nested field type filter AND specified nested filter by the user are cached in the bitset filter cache.

In the case of #31554 this ended up being cached: +_type:__nested1 #ToParentBlockJoinQuery (nested1.nested1_keyword:nested1_foo). I would only expect +_type:__nested1 to be cached by the bitset filter cache.

I think this is not intended and if many different nested sort filter where to be specified in separate search requests then this could cause the bitset filter cache to consume a lot of jvm heap space.

The problem is in SortBuilder class line 251 where this happens: context.bitsetFilter(parentQuery)
and in the case of multi level sorting parentQuery could be set to the nested filter of the parent nested sort definition.

I'm not sure how this can be best be fixed. I'm opening this issue to track the problem.

@martijnvg martijnvg added >bug discuss :Search/Search Search-related issues that do not fall into other categories labels Jul 4, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@jimczi jimczi self-assigned this Jul 16, 2018
jimczi added a commit that referenced this issue Jul 20, 2018
The parent filter for nested sort should always match **all** parents regardless
of the child queries. It is used to find the boundaries of a single parent and we use
the child query to match all the filters set in the nested tree so there is no need to
repeat the nested filters.
With this change we ensure that we build bitset filters
only to find the root docs (or the docs at the level where the sort applies) that can be reused
among queries.

Closes #31554
Closes #32130
Closes #31783

Co-authored-by: Dominic Bevacqua <bev@treatwell.com>
jimczi added a commit that referenced this issue Jul 20, 2018
The parent filter for nested sort should always match **all** parents regardless
of the child queries. It is used to find the boundaries of a single parent and we use
the child query to match all the filters set in the nested tree so there is no need to
repeat the nested filters.
With this change we ensure that we build bitset filters
only to find the root docs (or the docs at the level where the sort applies) that can be reused
among queries.

Closes #31554
Closes #32130
Closes #31783

Co-authored-by: Dominic Bevacqua <bev@treatwell.com>
jimczi added a commit that referenced this issue Jul 20, 2018
The parent filter for nested sort should always match **all** parents regardless
of the child queries. It is used to find the boundaries of a single parent and we use
the child query to match all the filters set in the nested tree so there is no need to
repeat the nested filters.
With this change we ensure that we build bitset filters
only to find the root docs (or the docs at the level where the sort applies) that can be reused
among queries.

Closes #31554
Closes #32130
Closes #31783

Co-authored-by: Dominic Bevacqua <bev@treatwell.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search/Search Search-related issues that do not fall into other categories
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants