You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a user knows that they want multiple different aggregations, they have to iterate the match-set once for each aggregation, which is inefficient. We can remedy this by enabling users to request more than one aggregation in a faceting call and then by handling all the computations in one go.
The text was updated successfully, but these errors were encountered:
I was thinking about this issue in connection with #12553. If accumulators were generic, that would give us multi-aggregations by default.
For example, if we're setting up an AVG aggregation, we would have an accumulator which maintains a sum and one which maintains a count, so we're actually doing two aggregations. An accumulator could encapsulate an arbitrary number of aggregations computed in one go.
This is a large change, refactoring most of the taxonomy facets code and changing internal behaviour, without changing the API. There are specific API changes this sets us up to do later, e.g. retrieving counts from aggregation facets.
1. Move most of the responsibility from TaxonomyFacets implementations to TaxonomyFacets itself. This reduces code duplication and enables future development. Addresses genericity issue mentioned in #12553.
2. As a consequence, introduce sparse values to FloatTaxonomyFacets, which previously used dense values always. This issue is part of #12576.
3. Compute counts for all taxonomy facets always, which enables us to add an API to retrieve counts for association facets in the future. Addresses #11282.
4. As a consequence of having counts, we can check whether we encountered a label while faceting (count > 0), while previously we relied on the aggregation value to be positive. Closes#12585.
5. Introduce the idea of doing multiple aggregations in one go, with association facets doing the aggregation they were already doing, plus a count. We can extend to an arbitrary number of aggregations, as suggested in #12546.
6. Don't change the API. The only change in behaviour users should notice is the fix for non-positive aggregation values, which were previously discarded.
7. Add tests which were missing for sparse/dense values and non-positive aggregations.
Description
When a user knows that they want multiple different aggregations, they have to iterate the match-set once for each aggregation, which is inefficient. We can remedy this by enabling users to request more than one aggregation in a faceting call and then by handling all the computations in one go.
The text was updated successfully, but these errors were encountered: