@gortiz Can you help check if this also solves the problem? I feel this is a safer option without changing the query plan

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.96%. Comparing base (59551e4) to head (9ea9e40).
Report is 764 commits behind head on master.

@@             Coverage Diff              @@
##             master   #13614      +/-   ##
============================================
+ Coverage     61.75%   61.96%   +0.21%     
+ Complexity      207      198       -9     
============================================
  Files          2436     2555     +119     
  Lines        133233   140710    +7477     
  Branches      20636    21862    +1226     
============================================
+ Hits          82274    87190    +4916     
- Misses        44911    46885    +1974     
- Partials       6048     6635     +587     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This patch is not enough. There are several places where SEARCH is converted into ORs. This patch is attacking one of the places (our expand rule) but not the other I know, which is when calcite validates queries. There, Calcite uses SqlToRelConverter.Config.inSubQueryThreshold to decide whether INs are going to be converted into ORs or not. The default value is 20, which means that any IN with less than 20 literals is converted into ORs while in the other case it is kept as IN and considered a subquery. Later in the pipeline (I don't know exactly where yet) the IN subquery is converted into an actual subquery which in our case is evaluated as a pipeline breaker.

Discussed offline. We will merge this one to reduce the overhead, in the meanwhile trying to figure out a thorough solution.