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.
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:__nested1to 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
SortBuilderclass line 251 where this happens:context.bitsetFilter(parentQuery)and in the case of multi level sorting
parentQuerycould 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.