thotashashank302 opened a new pull request, #19821: URL: https://github.com/apache/pinot/pull/19821
Fixes #19815 ## Summary When a scalar call on literal arguments is left for multi-stage execution, `FunctionOperand` invokes it again for every row. Cache its converted result lazily when all operands are `LiteralOperand` instances and the function is `IMMUTABLE`. This also covers immutable functions that opt out of planner folding. The cache belongs to one operand instance and includes null results. Calls with column or function arguments and STABLE/VOLATILE functions retain their existing behavior. Construction and empty inputs do not invoke the function; evaluation and conversion errors are still raised during execution. Cached objects are shared, matching `LiteralOperand`'s read-only result contract. This is independent of #19552 and introduces no configuration, public API, or serialized-format change. ## Testing - New `FunctionOperandTest`: 14 cases. Eight fail on unchanged production code; all 14 pass with the fix. - Existing `TransformOperatorTest`: all nine tests pass. The combined targeted run has 23 tests, zero failures/errors/skips. - Coverage includes non-foldable immutable functions, zero-argument and variable-argument calls, nulls, argument/result conversion, lazy errors, changing functions, row-dependent/nested expressions, instance isolation, and reuse across empty/nonempty blocks. - Affected-module Spotless, Checkstyle, license formatting, and license validation pass. `git diff --check` passes. - Full reactor `clean install -Pbin-dist`: failed in unchanged `pinot-core`, at `QueryRoutingTest.testLatencyForNoException:389` (latency assertion). That module ran 8,095 tests with one failure, zero errors, and one skip. Downstream modules were not reached. `pinot-core` does not depend on the changed runtime module. - Complete `pinot-query-runtime` suite: 4,960 tests, zero failures/errors, 18 skipped; Maven BUILD SUCCESS. ## Allocation check A task-local harness used the actual compiled `FunctionOperand` and existing `generateIntArray(0, 9999, 1)` implementation. It validated array length/endpoints while consuming 20,000 rows per measured round. Three fresh JVM pairs alternated baseline/candidate order; each JVM used three warmups, five measured rounds, JDK 25.0.4.1 on macOS ARM64, and a 512 MB heap. Thread-allocated bytes per row fell from 40,016 to approximately 2 for literal arguments (one array amortized over the run). A column-argument control remained at 40,016 bytes per row. This is bounded allocation evidence, not an end-to-end query latency or throughput claim. -- 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]
