amogh-jahagirdar commented on code in PR #11982:
URL: https://github.com/apache/iceberg/pull/11982#discussion_r1925722877
##########
spark/v3.5/spark/src/main/java/org/apache/iceberg/spark/actions/RewriteTablePathSparkAction.java:
##########
@@ -728,4 +724,22 @@ private String getMetadataLocation(Table tbl) {
!metadataDir.isEmpty(), "Failed to get the metadata file root
directory");
return metadataDir;
}
+
+ @VisibleForTesting
+ Broadcast<Table> tableBroadcast() {
+ if (tblBroadcast == null) {
+ this.tblBroadcast =
sparkContext().broadcast(SerializableTableWithSize.copyOf(table));
+ }
+
+ return tblBroadcast;
+ }
+
+ @VisibleForTesting
+ Broadcast<Map<Integer, PartitionSpec>> specsBroadcast(Map<Integer,
PartitionSpec> specsById) {
Review Comment:
Agreed, I think the original implementation had 2 broadcasts but there's
really no need for it as far as I can tell.
##########
spark/v3.5/spark/src/main/java/org/apache/iceberg/spark/actions/RewriteTablePathSparkAction.java:
##########
@@ -96,6 +98,8 @@ public class RewriteTablePathSparkAction extends
BaseSparkAction<RewriteTablePat
private String stagingDir;
private final Table table;
+ private Broadcast<Table> tblBroadcast = null;
+ private Broadcast<Map<Integer, PartitionSpec>> specsBroadcast = null;
Review Comment:
I feel like we don't really need 2 broadcasts here. The serialized table
will contain the serialized specs and that should just work. I think this may
just be a remnant of the original implementation but we can clean that up so
that we don't have a duplicate specs maps in memory on every executor.
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
