Gabriel39 commented on code in PR #66778:
URL: https://github.com/apache/doris/pull/66778#discussion_r3783788372


##########
fe/fe-connector/fe-connector-iceberg/src/main/java/org/apache/doris/connector/iceberg/IcebergScanPlanProvider.java:
##########
@@ -1241,45 +1235,138 @@ private static Schema pinnedSchema(Table table, 
IcebergTableHandle handle) {
     }
 
     /**
-     * Emit the single collapsed COUNT(*)-pushdown range: the first whole-file 
{@link FileScanTask} from
-     * {@code scan.planFiles()} carrying the full {@code realCount} via {@code 
table_level_row_count} → BE's
-     * count reader serves it without opening the data file. Mirrors paimon's 
{@code buildCountRange} (one
-     * range bearing the summed total). Result-identical to legacy's count 
short-circuit even though legacy
-     * takes a different shape: legacy byte-splits the count file ({@code 
planFileScanTask} →
-     * {@code splitFiles} → {@code TableScanUtil.splitFiles}), keeps the first 
split task's byte-range for
-     * {@code count < 10000}, and {@code assignCountToSplits} distributes the 
same total — but under count
-     * pushdown BE's count reader never reads the file (the range's 
start/length are irrelevant) and sums
-     * {@code table_level_row_count} across ranges, so one whole-file range 
yields the identical total (and
-     * legacy's {@code >10000} parallel multi-split trim is the perf-only 
divergence we drop). An empty table
-     * (no files) yields no range, so BE gets 0 ranges and COUNT returns 0 
(legacy returns empty splits too).
+     * Build a collapsed COUNT(*) range from current manifest-list aggregates. 
Summing each data manifest's
+     * added and existing row counts is O(manifests), while only the first 
live {@link FileScanTask} is needed as
+     * the representative range. Old manifest lists that omit these aggregates 
use the bounded O(files) fallback.
+     * Any live delete file makes the optimization unsafe and tells the caller 
to perform a normal scan.
      */
-    private List<ConnectorScanRange> planCountPushdown(Table table, TableScan 
scan, long realCount,
+    private Optional<List<ConnectorScanRange>> planCountPushdown(Table table, 
TableScan scan,
+            int formatVersion, boolean partitioned, List<String> 
orderedPartitionKeys, ZoneId zone,
+            UnaryOperator<String> uriNormalizer, ConnectorSession session, 
Optional<ConnectorExpression> filter) {
+        Snapshot snapshot = scan.snapshot();
+        if (snapshot == null) {
+            return Optional.of(Collections.emptyList());
+        }
+
+        ManifestDeleteState deleteState = 
manifestDeleteState(snapshot.deleteManifests(table.io()));
+        if (deleteState == ManifestDeleteState.PRESENT) {

Review Comment:
   Follow-up corrected in 12476576e1d. My previous reply misstated the 
compatibility contract: when the flag is enabled, the legacy numeric behavior 
is data rows minus current position-delete record counts, not raw data rows. 
The V2 path now derives both values from live manifests without trusting 
optional snapshot-summary counters, subtracts each live position-delete file 
once, and keeps equality deletes on the normal scan path. The unit expectation 
is restored from 10 to 7; V1 logic remains unchanged.



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