gianm commented on a change in pull request #10613:
URL: https://github.com/apache/druid/pull/10613#discussion_r558124796
##########
File path:
processing/src/main/java/org/apache/druid/segment/DimensionHandlerUtils.java
##########
@@ -305,17 +305,29 @@ private static ColumnCapabilities
getEffectiveCapabilities(
originalCapabilities == null ||
ValueType.COMPLEX.equals(originalCapabilities.getType());
if (type == ValueType.STRING) {
- if (!forceSingleValue &&
effectiveCapabilites.hasMultipleValues().isMaybeTrue()) {
- return strategyFactory.makeMultiValueDimensionProcessor(
- effectiveCapabilites,
- selectorFactory.makeMultiValueDimensionSelector(dimensionSpec)
- );
- } else {
- return strategyFactory.makeSingleValueDimensionProcessor(
- effectiveCapabilites,
- selectorFactory.makeSingleValueDimensionSelector(dimensionSpec)
- );
+ if (!forceSingleValue) {
+ // if column is not dictionary encoded (and not non-existent or
complex), use object selector
+ if (effectiveCapabilites.isDictionaryEncoded().isFalse() ||
+ effectiveCapabilites.areDictionaryValuesUnique().isFalse()
Review comment:
I think your reasoning makes sense, and it sounds like your assumption
is that when selecting string-typed things that aren't dictionary-encoded, we
should prefer the object selector vs. one of the DimensionVectorSelectors,
because that'll incur less overhead.
This logic should be spelled out somewhere though. IMO javadocs on the
appropriate methods in VectorColumnSelectorFactory is the best place. They
should say when callers should prefer using the object selector vs. the more
specifically-typed selectors.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]