You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Bruce Robbins (Jira)" <ji...@apache.org> on 2025/07/28 19:26:00 UTC
[jira] [Updated] (SPARK-52873) Hint causes semi join results to vary
[ https://issues.apache.org/jira/browse/SPARK-52873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruce Robbins updated SPARK-52873:
----------------------------------
Labels: correctness (was: )
> Hint causes semi join results to vary
> -------------------------------------
>
> Key: SPARK-52873
> URL: https://issues.apache.org/jira/browse/SPARK-52873
> Project: Spark
> Issue Type: Bug
> Components: Spark Core, SQL
> Affects Versions: 3.4.1, 3.5.3, 3.5.5
> Reporter: Peter Connolly
> Priority: Major
> Labels: correctness
>
> I was running a query in production that was not getting the expected results. I suspect that this query is using an improper join type for a semi join with a non-equal predicate.
> While my production code has no query hint I am able to reproduce the issue consistently by doing a semi join with a hint in some sample code. In this sample code I create two dataframes, one of which has strings and another that I want to match on the first x characters using a startswith clause. I realize that the substring equality join is logically redundant and could be theoretically removed, but it helps greatly with performance in production. I then run two queries that are nearly identical to find records that match. The only difference between the queries is that the second query has a join hint. Despite being the same logical query they produce different output.
> {code:java}
> import spark.implicits._
> val geohashes = Seq(
> ("9ykchgz95z"),
> ("abckd3kdf1"),
> ).toDF("geohash")
> .repartition(2)
> geohashes.createOrReplaceTempView("geohashes")
> val geohashesToInclude = Seq(
> ("9ykchgz91"),
> ("9ykchgz92"),
> ("9ykchgz93"),
> ("9ykchgz94"),
> ("9ykchgz95"),
> ("9ykchgz96"),
> ("9ykchgz97"),
> ("9ykchgz98"),
> ("9ykchgz99"),
> ("9ykchgz90"),
> ).toDF("geohash_prefix")
> .repartition(10)
> geohashesToInclude.createOrReplaceTempView("geohashes_to_include")
> spark.sql("SELECT * FROM geohashes g LEFT SEMI JOIN geohashes_to_include i ON SUBSTRING(g.geohash, 1, 7) = SUBSTRING(i.geohash_prefix, 1, 7) AND STARTSWITH(g.geohash, i.geohash_prefix)").show()
> +----------+
> | geohash|
> +----------+
> |9ykchgz95z|
> +----------+
> spark.sql("SELECT /*+ SHUFFLE_HASH(i) */ * FROM geohashes g LEFT SEMI JOIN geohashes_to_include i ON SUBSTRING(g.geohash, 1, 7) = SUBSTRING(i.geohash_prefix, 1, 7) AND STARTSWITH(g.geohash, i.geohash_prefix)").show()
> +-------+
> |geohash|
> +-------+
> +-------+ {code}
> I produced the above sample on spark 3.5.3, but I think I have observed similar issues in production code in spark 3.4.1 and 3.5.5 (the latest version on EMR).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org