gortiz commented on PR #13174:
URL: https://github.com/apache/pinot/pull/13174#issuecomment-4779222412
Closing this PR as superseded.
This was always a self-admitted hack, and the proper fixes I suggested in
the description — *"support SEARCH in V1"* / centralized handling instead of
expanding SEARCH into filter trees — were implemented upstream by #14615
("Improve performance of multi-stage queries with large IN clauses", merged Mar
2025).
That PR:
- Removed `PinotFilterExpandSearchRule` entirely, so SEARCH nodes are no
longer expanded into AND/OR predicate trees at planning time.
- Handles SEARCH directly in `RexExpressionUtils`, and — most relevant here
— when the left operand is a literal, evaluates the `Sarg` to
`Literal.TRUE`/`Literal.FALSE` at conversion time (`evaluateLiteralIn` /
`evaluateLiteralNotIn` / `evaluateLiteralOrRanges`). This eliminates the
tautology at its source rather than relying on a second
`FILTER_REDUCE_EXPRESSIONS` pass to clean it up.
- Added regression coverage (`literal_planning_cte_tests` in
`LiteralEvaluationPlans.json`) for the exact CTE-with-literal-filter scenario
this PR targeted; it now plans to `LogicalValues(tuples=[[]])`.
So the root cause is gone and the rule this PR modified no longer exists.
The only independently-useful leftovers were the per-stage debug logging in
`QueryEnvironment` and the test `log4j2.xml`; if still wanted, those can be
picked up in a small standalone PR.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
