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]

Reply via email to