andygrove commented on PR #5889: URL: https://github.com/apache/datafusion-comet/pull/5889#issuecomment-6425145597
@sunchao, to make the scope concrete for the next push, here is where I think each of your open findings belongs. The [`IN`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085457), [`AND`/`OR`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085460), [nullable operand](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085463) and [`concat`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085468) findings are #7246. The same queries fail on main with a plain subquery or a literal, so they don't need a fix in this PR. The width findings ([field expansion](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4332877116), [whole-struct sources](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4357862495), [operator boundaries](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085474), [`CheckOverflow`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085476) and [`repeat`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085478)) are #7247. If the field read returns a scalar the way a plain subquery does, instead of expanding to the batch length, the merged form behaves like the plain one and the bounded consumer evaluation isn't needed. The [literal origin](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085482), [integer cast](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085484) and [array constructor](https://github.com/apache/datafusion-comet/pull/5889#discussion _r4367085485) slowdowns come from that evaluation, so they go away with it. The [fixed-offset array](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4316013895), [padding](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4321296723), [regional clock](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085470) and [scalar `Date32`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4367085473) findings are about the scalar-argument kernels, so they belong with the fixes for #3336 and #7245. Those should land before the struct support, so that merged subqueries never reach a kernel that rejects scalars. The [`TruncDate`](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4321296726) finding is #6843, which affects plain date columns on main too. The [merged Bloom filter](https://github.com/apache/datafusion-comet/pull/5889#discussion_r4361964356) planning failure is specific to struct results, so it still needs to work here. With a scalar field read, `BloomFilterMightContain::try_new` gets the scalar binary value it expects. -- 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]
