HIVE-29853: Iceberg CompactionEvaluator double-counts input files

[Aggarwal-Raghav]

What changes were proposed in this pull request?

Removed the redundant call to addFiles() from the CompactionEvaluator constructor.

Why are the changes needed?

The addFiles() iterates through a table's Iceberg snapshot and adds files to the CommonPartitionEvaluator. Because this was being called in both the constructor and again in isEligibleForCompaction(), every file and byte was double-counted in memory.

Does this PR introduce any user-facing change?

Yes. The evaluator will now accurately respect the configured byte sizes and file count thresholds (compactor.threshold.target.size and compactor.threshold.min.input.files).

How was this patch tested?

CI outcome

[Aggarwal-Raghav]

CC @difin

[Aggarwal-Raghav]

addFiles is here as well. So two times counting same data files. To keep the intention of q files same I have just pumped up more inserts to incease the total file size to be eligibe for compaction. The failinig q files can be checked in run 1

[Aggarwal-Raghav]

Flaky test failure, re-triggering the CI

[Aggarwal-Raghav]

Resolving merge conflicts.

[Aggarwal-Raghav]

CC @deniskuzZ , requesting review

[Aggarwal-Raghav]

rebased to resolve another merge conflict

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[deniskuzZ]

cc @difin

[deniskuzZ]

@Aggarwal-Raghav why change existing qfile? it's hard to follow if there is any regression in q.out

[Aggarwal-Raghav]

@Aggarwal-Raghav why change existing qfile? it's hard to follow if there is any regression in q.out

@deniskuzZ , The run1 as I mentioned in initial comment is gone from jenkins. I have attached local q.out diff with just *.java changes. The insert statements / data is controlling the compaction eligibility. As the double Counting is fixed the more data is required to ensure the compaction passes.