HeartSaVioR commented on code in PR #39082:
URL: https://github.com/apache/spark/pull/39082#discussion_r1051306854
##########
sql/core/src/main/scala/org/apache/spark/sql/execution/ExistingRDD.scala:
##########
@@ -183,16 +172,80 @@ object LogicalRDD {
}
}
+ val logicalPlan = originDataset.logicalPlan
val optimizedPlan = originDataset.queryExecution.optimizedPlan
val executedPlan = originDataset.queryExecution.executedPlan
+ val (stats, constraints) = rewriteStatsAndConstraints(logicalPlan,
optimizedPlan)
+
LogicalRDD(
originDataset.logicalPlan.output,
rdd,
firstLeafPartitioning(executedPlan.outputPartitioning),
executedPlan.outputOrdering,
isStreaming
- )(originDataset.sparkSession, Some(optimizedPlan.stats),
Some(optimizedPlan.constraints))
+ )(originDataset.sparkSession, stats, constraints)
+ }
+
+ private[sql] def buildOutputAssocForRewrite(
+ source: Seq[Attribute],
+ destination: Seq[Attribute]): Option[Map[Attribute, Attribute]] = {
+ // We check the name and type, allowing nullability, exprId, metadata,
qualifier be different
+ // E.g. This could happen during optimization phase.
+ val rewrite = source.zip(destination).flatMap { case (attr1, attr2) =>
+ if (attr1.name == attr2.name && attr1.dataType == attr2.dataType) {
+ Some(attr1 -> attr2)
+ } else {
+ None
+ }
+ }.toMap
+
+ if (rewrite.size == source.size) {
+ Some(rewrite)
+ } else {
+ None
+ }
+ }
+
+ private[sql] def rewriteStatsAndConstraints(
+ logicalPlan: LogicalPlan,
+ optimizedPlan: LogicalPlan): (Option[Statistics], Option[ExpressionSet])
= {
+ val rewrite = buildOutputAssocForRewrite(optimizedPlan.output,
logicalPlan.output)
+
+ rewrite.map { rw =>
+ val rewrittenStatistics = rewriteStatistics(optimizedPlan.stats, rw)
+ val rewrittenConstraints = rewriteConstraints(optimizedPlan.constraints,
rw)
+
+ (Some(rewrittenStatistics), Some(rewrittenConstraints))
+ }.getOrElse {
+ // can't rewrite stats and constraints, give up
+ logWarning("The output columns are expected to the same (for name and
type) for output " +
Review Comment:
Yeah my understanding is that the final output after optimization should be
semantically same. Looks like exprId can change, but I'm not sure what else we
allow to be changed.
My feeling is that changes on type or nullability could also break DSv1
sink, if the change is not done with "compatible way". e.g. table in sink has a
column nullability set to "false", and optimizer somehow (shouldn't happen but)
changes nullability of a column from "false" to "true" (again, shouldn't
happen). Same applies to data type as well. I feel column order also matters,
but not sure we pretend that the consumer should access column by name.
--
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]
