huaxingao commented on code in PR #18002:
URL: https://github.com/apache/iceberg/pull/18002#discussion_r3954309243


##########
core/src/main/java/org/apache/iceberg/BaseContentScanTask.java:
##########
@@ -104,6 +104,8 @@ public Iterable<ThisT> split(long targetSplitSize) {
         return () ->
             new OffsetsAwareSplitScanTaskIterator<>(
                 self(), length(), splitOffsets, this::newSplitTask);
+      } else if (length() <= targetSplitSize) {
+        return ImmutableList.of(self());

Review Comment:
   nit: for length() == 0 the old path produced zero splits 
(FixedSizeSplitScanTaskIterator.hasNext() is remainingLength > 0), while the 
new branch returns one zero-length task. I think the new behavior is the better 
one, since a task silently vanishing from the scan is worse and this matches 
what the non-splittable path already does. Could you note it in the PR 
description?



##########
core/src/test/java/org/apache/iceberg/util/TestTableScanUtil.java:
##########
@@ -332,6 +332,42 @@ public void testAdaptiveSplitSize() {
         .hasMessageStartingWith("Parallelism must be > 0: 0");
   }
 
+  @Test
+  public void testSplitSkipsWrapWhenFileFitsSingleSplit() {
+    // A small splittable file (no offsets) smaller than the target split size 
must not be wrapped
+    // in a redundant 1:1 SplitScanTask; split() should return the task itself.
+    BaseFileScanTask task = newScanTask(FileFormat.PARQUET, 64L);

Review Comment:
   nit: should we also cover `length() == targetSplitSize`? 



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

Reply via email to