When creating the list of aggs (filtered and non-filtered)[1], function is checked for nullness and only if non-null, added to filteredAggregations list. Later, in AggregationFunctionUtils, .getLeft() is checked for nullness and used as a way to partition aggs with/without filters applied[2]. getLeft is never null because of the null check performed in [1]. Therefore no aggs are registered as being paired with the main predicate, instead causing the main filter predicate plan to .run() for each iteration of the loop[3][4] (buildFilterOperator -> new FilterPlanNode with accidental null filterContext i.e. use main filter predicate). Then, a CombinedFilterOperator is created using effectively 2 copies of mainPredicate AND’d together, and a pre-scan of the duplicated main predicate is run for each block[5][6]

I believe that the intent was to use getRight() (i.e. the filter context) for nullness check in [2] rather than [1]. I have this as a draft because BenchmarkQueries.java still seems to indicate that FILTER is significantly slower than CASE in some test scenarios, so there may be more to it.

Separately, an extra empty AggregationFunction[] was being added to any query with only filtered aggs and no non-filtered aggs, causing many docs to be scanned without any purpose.

BenchmarkQueries.java now shows that FITLER is always as fast as CASE, often faster (just depends on index usage, mostly, but at least it’s never slower).

[1]