mikemccand commented on PR #13568: URL: https://github.com/apache/lucene/pull/13568#issuecomment-2250254223
> > 5\. This is speculative, but let's say we want to support non-decomposable aggregations in the future, e.g. percentiles, which require the recorder to store all the values until we reduce. If I want p99, p99.9, and p99.99, I don't want to store the values three times, once for each recorder, which is how it would work with `MultiFacetsRecorder`. Maybe in the future there is a place for a recorder that can be reduced many different ways. To put it another way, recording and reducing could be decoupled. But like I said, this is a lot of speculation and I don't suggest we change it in this PR. > > Interesting idea, I think we would have to come up with a new recorder implementation, which can take required percentiles as constructor arguments, and do what you suggest - record values for each doc and build results in `reduce`, or alternatively use some approximation algorithm (e.g. [this](https://github.com/timescale/timescaledb-toolkit/blob/main/docs/uddsketch.md)) [HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) is maybe another example of an unusual recorder (future!). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
