Open leventov opened 5 years ago
@leventov I will work on this one.
I accidentally stumbled into this by suggesting the opposite refactoring on #7496: https://github.com/apache/incubator-druid/pull/7496#discussion_r276413326. I think the way that CardinalityAggregator works now is pretty nice, for the reasons I mentioned in that thread. I'm not really interested in requiring that everything be done that way but I did want to speak up for why the design is the way it is.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is no longer marked as stale.
This issue has been marked as stale due to 280 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the dev@druid.apache.org list. Thank you for your contributions.
The logic of
CardinalityAggregatorColumnSelectorStrategyFactory
could be inlined inCardinalityAggregatorFactory.factorize()
andfactorizeBuffered()
methods, and the logic ofCardinalityAggregatorColumnSelectorStrategy
could be expressed in subclasses ofCardinalityBufferAggregator
andCardinalityAggregator
.This change is similar to what is proposed here: https://github.com/apache/incubator-druid/pull/6397#discussion_r250564034