[
https://issues.apache.org/jira/browse/SPARK-26203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16718191#comment-16718191
]
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-446404185
**[Test build #99993 has
finished](https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/99993/testReport)**
for PR 23291 at commit
[`987bea4`](https://github.com/apache/spark/commit/987bea48350ed2e3862b965e07d5d5335e1d86c2).
* This patch **fails to generate documentation**.
* This patch merges cleanly.
* This patch adds no public classes.
----------------------------------------------------------------
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
