[test](update)

[zhangstar333]

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[zhangstar333]

/review

[zhangstar333]

run buildall

[github-actions]

Overall, I found no blocking issues in this PR.

Critical checkpoints:

• Goal / correctness: The change aims to defer Iceberg Parquet position-delete / deletion-vector loading until a row group actually survives row-group filtering. The implementation matches that goal: IcebergTableReader::init_row_filters() now defers only the Parquet position-delete and DV paths, and ParquetReader::_next_row_group_reader() executes the loader immediately before building the first surviving row-group reader.
• Scope / minimality: The change is small and focused. It only adds a lazy loader hook in ParquetReader plus the Iceberg-side wiring needed to preserve delete-awareness before the loader runs.
• Concurrency: I did not find a new concurrency risk. The deferred loader is per-reader state, runs on the scan path before row-group initialization, and does not introduce new lock ordering or shared mutable state beyond the existing KV-cache usage.
• Lifecycle / initialization: No special lifecycle or static-initialization hazard was introduced. The deferred callback is owned by the reader instance and cleared after successful execution.
• Configuration: No new config items.
• Compatibility: No FE/BE protocol, storage-format, or rolling-upgrade compatibility issue in this change.
• Parallel code paths: Equality deletes remain eager, and ORC keeps the existing eager behavior. That split is appropriate because only the Parquet position-delete / DV path can safely benefit from row-group filtering before delete rows are needed.
• Special condition checks: The single-DV validation is preserved, and the new eager-vs-deferred branches are documented clearly enough to explain why the behavior differs by delete type / file format.
• Test coverage: This is the main gap. I do not see added regression or unit coverage for the new lazy-loading behavior, so the PR currently relies on reasoning rather than a test that proves both cases: all row groups filtered => delete files are not read, and at least one row group survives => deletes are still applied correctly.
• Test result updates: None in this PR.
• Observability: Existing delete-file / delete-row profile counters remain in place. No additional observability looks required for this small optimization.
• Transaction / persistence: Not applicable; this is a read-path change only.
• Data writes / atomicity: Not applicable; no write-side logic changed.
• FE-to-BE variable passing: Not applicable; no new transmitted fields.
• Performance: The change should reduce unnecessary delete-file I/O when Parquet row-group pruning eliminates the file, and I did not find an obvious hot-path regression.
• Other issues: No additional blocking issues found in the surrounding call chain.

Residual risk:

• The correctness-sensitive delete path now depends on deferred execution, so adding targeted coverage would make this change much safer to maintain.

[hello-stephen]

BE UT Coverage Report

Increment line coverage 11.90% (5/42) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	53.12% (20190/38011)
Line Coverage	36.68% (190134/518291)
Region Coverage	32.91% (147517/448206)
Branch Coverage	34.07% (64633/189691)

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 100.00% (42/42) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	73.71% (27437/37225)
Line Coverage	57.38% (296505/516708)
Region Coverage	54.52% (246589/452330)
Branch Coverage	56.28% (107091/190267)