[ https://issues.apache.org/jira/browse/SPARK-26203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717779#comment-16717779 ]
ASF GitHub Bot commented on SPARK-26203: ---------------------------------------- SparkQA commented on issue #23291: [SPARK-26203][SQL] Benchmark performance of In and InSet expressions URL: https://github.com/apache/spark/pull/23291#issuecomment-446324303 **[Test build #99987 has started](https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/99987/testReport)** for PR 23291 at commit [`6a5e992`](https://github.com/apache/spark/commit/6a5e992a3f940b7e85d11c5964086e3a6185e81c). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Benchmark performance of In and InSet expressions > ------------------------------------------------- > > Key: SPARK-26203 > URL: https://issues.apache.org/jira/browse/SPARK-26203 > Project: Spark > Issue Type: Test > Components: SQL > Affects Versions: 3.0.0 > Reporter: Anton Okolnychyi > Priority: Major > > {{OptimizeIn}} rule replaces {{In}} with {{InSet}} if the number of possible > values exceeds "spark.sql.optimizer.inSetConversionThreshold" and all values > are literals. This was done for performance reasons to avoid O\(n\) time > complexity for {{In}}. > The original optimization was done in SPARK-3711. A lot has changed after > that (e.g., generation of Java code to evaluate expressions), so it is worth > to measure the performance of this optimization again. > According to my local benchmarks, {{InSet}} can be up to 10x time slower than > {{In}} due to autoboxing and other issues. > The scope of this JIRA is to benchmark every supported data type inside > {{In}} and {{InSet}} and outline existing bottlenecks. Once we have this > information, we can come up with solutions. > Based on my preliminary investigation, we can do quite some optimizations, > which quite frequently depend on a specific data type. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org