clintropolis commented on a change in pull request #10613:
URL: https://github.com/apache/druid/pull/10613#discussion_r578961003



##########
File path: 
processing/src/main/java/org/apache/druid/segment/filter/ExpressionFilter.java
##########
@@ -55,6 +69,105 @@ public ExpressionFilter(final Supplier<Expr> expr, final 
FilterTuning filterTuni
     this.filterTuning = filterTuning;
   }
 
+  @Override
+  public boolean canVectorizeMatcher(ColumnInspector inspector)
+  {
+    return expr.get().canVectorize(inspector);
+  }
+
+  @Override
+  public VectorValueMatcher makeVectorMatcher(VectorColumnSelectorFactory 
factory)
+  {
+    final Expr theExpr = expr.get();
+
+    DruidPredicateFactory predicateFactory = new DruidPredicateFactory()
+    {
+      @Override
+      public Predicate<String> makeStringPredicate()
+      {
+        return Evals::asBoolean;
+      }
+
+      @Override
+      public DruidLongPredicate makeLongPredicate()
+      {
+        return Evals::asBoolean;
+      }
+
+      @Override
+      public DruidFloatPredicate makeFloatPredicate()
+      {
+        return Evals::asBoolean;
+      }
+
+      @Override
+      public DruidDoublePredicate makeDoublePredicate()
+      {
+        return Evals::asBoolean;
+      }
+
+      // The hashcode and equals are to make 
SubclassesMustOverrideEqualsAndHashCodeTest stop complaining..
+      // DruidPredicateFactory doesn't really need equals or hashcode, in fact 
only the 'toString' method is called
+      // when testing equality of DimensionPredicateFilter, so it's the truly 
required method, but even that seems
+      // strange at best.
+      // Rather than tackle removing the annotation and reworking equality 
tests for now, will leave this to refactor
+      // as part of https://github.com/apache/druid/issues/8256 which suggests 
combining Filter and DimFilter
+      // implementations, which should clean up some of this mess.
+      @Override
+      public int hashCode()
+      {
+        return super.hashCode();
+      }
+
+      @Override
+      public boolean equals(Object obj)
+      {
+        return super.equals(obj);
+      }
+    };
+
+
+    final ExprType outputType = theExpr.getOutputType(factory);
+
+    if (outputType == null) {
+      // if an expression is vectorizable, but the output type is null, the 
result will be null (or the default
+      // value in default mode) because expression is either all null 
constants or missing columns
+
+      // in sql compatible mode, this means no matches ever, so just use the 
false matcher:
+      if (NullHandling.sqlCompatible()) {
+        return new FalseVectorMatcher(factory.getVectorSizeInspector());
+      }
+      // in default mode, just fallback to using a long matcher since nearly 
all boolean-ish expressions
+      // output a long value so it is probably a safe bet? idk, ending up here 
by using all null-ish things
+      // in default mode is dancing on the edge of insanity anyway...
+      return 
VectorValueMatcherColumnProcessorFactory.instance().makeLongProcessor(
+          
ColumnCapabilitiesImpl.createSimpleNumericColumnCapabilities(ValueType.LONG),
+          ExpressionVectorSelectors.makeVectorValueSelector(factory, theExpr)
+      ).makeMatcher(predicateFactory);
+    }
+
+    switch (outputType) {
+      case LONG:
+        return 
VectorValueMatcherColumnProcessorFactory.instance().makeLongProcessor(
+            
ColumnCapabilitiesImpl.createSimpleNumericColumnCapabilities(ValueType.LONG),
+            ExpressionVectorSelectors.makeVectorValueSelector(factory, theExpr)
+        ).makeMatcher(predicateFactory);
+      case DOUBLE:
+        return 
VectorValueMatcherColumnProcessorFactory.instance().makeDoubleProcessor(
+            
ColumnCapabilitiesImpl.createSimpleNumericColumnCapabilities(ValueType.DOUBLE),
+            ExpressionVectorSelectors.makeVectorValueSelector(factory, theExpr)
+        ).makeMatcher(predicateFactory);
+      case STRING:
+        return 
VectorValueMatcherColumnProcessorFactory.instance().makeObjectProcessor(
+            // using 'numeric' capabilities creator so we are configured to 
NOT be dictionary encoded, etc
+            
ColumnCapabilitiesImpl.createSimpleNumericColumnCapabilities(ValueType.STRING),

Review comment:
       added a `createSimpleStringColumnCapabilities`




----------------------------------------------------------------
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:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org
For additional commands, e-mail: commits-h...@druid.apache.org

Reply via email to