gortiz commented on issue #12647: URL: https://github.com/apache/pinot/issues/12647#issuecomment-2301307638
Thanks @bziobrowski for debugging this. Your solution seems interesting, but it is partial. Pinot has 2 different engines. The original one (we call single-stage or V1) uses Calcite just to parse the expression and apply some simplifications while most of the logical to physical transformations are applied eagerly by our own code. Then we have a second engine (called multi-stage or V2) that relay more in Calcite. This second engine ends up calling the single-stage engine in the leaves of the execution tree. If I remember correctly, this issue was detected when adding AGGREGATE_CASE_TO_FILTER and we found it affects both single and multi stage. As you say it seems that FilteredGroupByOperator is involved. That class is used in single-stage. Your first suggestion may be useful, but it is limited to multi-stage and it would end up producing inefficient plans. The reason to merge #12643 was to try to use some indexes we cannot use in filtered aggregations. Also, I'm not sure what do you mean with keyed aggregation. Do you mean using `group by k1, k2, etc`? I don't think that is an actual problematic case. Instead the problem arise when using two aggregate functions and only one of them is filtered. BTW, it looks like this issue was reported twice (see https://github.com/apache/pinot/issues/13749) and I think @Jackie-Jiang already fixed this in https://github.com/apache/pinot/pull/13784. -- 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: commits-unsubscr...@pinot.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org For additional commands, e-mail: commits-h...@pinot.apache.org
