From 203b7cc7c55775c4fb6389a7bb86635178a3a0e6 Mon Sep 17 00:00:00 2001 From: Nik Everett Date: Thu, 29 Jul 2021 17:26:02 -0400 Subject: [PATCH] Docs: Release notes for filter by filter fix (#75749) In #74260 we disabled the "filter by filter" aggregations optimizations when we couldn't be 100% sure that they were both faster and *safe* for the cluster. Before that, mostly in the 7.13 line, we would aggressively enable the optimization whenever we could and there were lots of cases where the well meaning optimization was way way slower than the original implementation. There were also cases where it'd fill up memory and knock over the cluster! Disaster. With #74260 we're safe. The optimization still kicks in when its faster - like when the top level query is empty - but otherwise it get's out of the way and lets all the normal aggs run. --- docs/reference/release-notes/7.14.asciidoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/reference/release-notes/7.14.asciidoc b/docs/reference/release-notes/7.14.asciidoc index 19c106b520abc..2f28c035703cf 100644 --- a/docs/reference/release-notes/7.14.asciidoc +++ b/docs/reference/release-notes/7.14.asciidoc @@ -20,3 +20,8 @@ Machine Learning:: * Make atomic operations safer for aarch64 {ml-pull}1893[#1893] * Ensure bucket event_count is calculated for jobs with 1 second bucket spans {ml-pull}1909[#1909] + +Aggregations:: + +* Only enable "filter by filter" optimization for `terms`, `date_histogram`, + `range`, and `fitlers` aggregation when we're sure it'll be faster {es-pull}74260[#74260]