[GitHub] [iceberg] kbendick commented on a change in pull request #2116: Optimize join types for MERGE INTO

[GitBox <gi...@apache.org>]

kbendick commented on a change in pull request #2116:
URL: https://github.com/apache/iceberg/pull/2116#discussion_r560467217



##########
File path: spark3-extensions/src/main/scala/org/apache/spark/sql/catalyst/optimizer/RewriteMergeInto.scala
##########
@@ -58,53 +61,138 @@ case class RewriteMergeInto(conf: SQLConf) extends Rule[LogicalPlan] with Rewrit
 
   override def apply(plan: LogicalPlan): LogicalPlan = {
     plan resolveOperators {
+      case MergeIntoTable(target: DataSourceV2Relation, source: LogicalPlan, cond, matchedActions, notMatchedActions)
+          if matchedActions.isEmpty =>
+
+        val mergeBuilder = target.table.asMergeable.newMergeBuilder("merge", newWriteInfo(target.schema))
+        val targetTableScan = buildSimpleScanPlan(target.table, target.output, mergeBuilder, cond)
+
+        // when there are no matched actions, use a left anti join to remove any matching rows and rewrite to use
+        // append instead of replace. only unmatched source rows are passed to the merge and actions are all inserts.
+        val joinPlan = Join(source, targetTableScan, LeftAnti, Some(cond), JoinHint.NONE)

Review comment:
       Somewhat unrelated inquiry for my own understanding: If we pass `JoinHint.NONE`, are we allowing for any optimizations to take place? Join hints are what they seem to be, just the hints that we pass in either via the comments like `/* SKEW('field') */` or via the functions like `broadcast`, right?
   
   In this case it likely doesn't matter much since this is being rewritten to an append, but I'm thinking if one of the tables is much smaller, a broadcast join might happen for example.
   
   My two questions would be:
   (1) In general, does passing in `JoinHint.NONE` stop spark from making its own calls on join types where it can using CBO etc?
   (2) Given that Iceberg has all of its own stats handling, is there a situation where the join hints are going to be very useful?

##########
File path: spark3-extensions/src/main/scala/org/apache/spark/sql/catalyst/optimizer/RewriteMergeInto.scala
##########
@@ -58,53 +61,136 @@ case class RewriteMergeInto(conf: SQLConf) extends Rule[LogicalPlan] with Rewrit
 
   override def apply(plan: LogicalPlan): LogicalPlan = {
     plan resolveOperators {
+      case MergeIntoTable(target: DataSourceV2Relation, source: LogicalPlan, cond, matchedActions, notMatchedActions)
+          if matchedActions.isEmpty =>
+
+        val (_, targetTableScan) = buildTargetScan(target, source, cond)
+
+        // when there are no matched actions, use a left anti join to remove any matching rows and rewrite to use
+        // append instead of replace. only unmatched source rows are passed to the merge and actions are all inserts.
+        val joinPlan = Join(source, targetTableScan, LeftAnti, Some(cond), JoinHint.NONE)
+
+        val mergeParams = MergeIntoParams(
+          isSourceRowNotPresent = FALSE_LITERAL,
+          isTargetRowNotPresent = TRUE_LITERAL,

Review comment:
       I agree on negating these conditions, possibly by having a shim we use for our own use cases. Having just reasoned about "not present" in `core` for NOT_STARTS_WITH, I can confirm that it is a pain and leads to confusion.




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org