[safaehar]

airflow db clean checks whether each batch contains rows before creating its archive table and deleting the batch. The result is used only as a boolean, but the current query counts every matching row up to the configured batch size.

This changes the per-batch probe from COUNT(*) to EXISTS. The database still evaluates the cleanup filters, but it can stop the probe after finding the first qualifying row instead of consuming the entire candidate batch. For example, cleaning 1,000,000 rows in 100 batches of 10,000 currently makes the boolean prechecks count up to 1,000,000 rows in total; with EXISTS, the non-empty prechecks need only find one qualifying row per batch. The delete or archive statement still selects each batch, and the final empty probe can still scan all relevant candidates when proving that no rows remain.

The batch selection, archive behavior, transaction boundaries, and initial exact count used for dry-run and progress output remain unchanged.

PostgreSQL probe benchmark

On a temporary PostgreSQL table with 1,000,000 rows, 500,000 eligible rows, an indexed cleanup timestamp, and warm buffers, EXPLAIN ANALYZE showed the following median results over seven runs:

Batch size	COUNT(*)	EXISTS	Tuples examined	Buffer blocks
1,000	0.120 ms	0.002 ms	1,000 → 1	37 → 1
10,000	1.172 ms	0.002 ms	10,000 → 1	343 → 1
100,000	14.098 ms	0.004 ms	100,000 → 1	3,401 → 1

This isolates the batch-emptiness probe rather than measuring end-to-end cleanup time. The archive/delete work is unchanged, absolute timings are environment-specific, and an empty-result probe may still scan all relevant candidates.

Tests

• uv run --project airflow-core pytest airflow-core/tests/unit/utils/test_db_cleanup.py::TestDBCleanup::test_do_delete_checks_batch_existence_without_counting_rows --with-db-init -xvs (passed)
• uv run --project airflow-core pytest airflow-core/tests/unit/utils/test_db_cleanup.py --with-db-init -xq (SQLite: 113 passed, 3 backend-specific skipped)
• env -u DOCKER_HOST DOCKER_CONTEXT=colima breeze run --backend sqlite pytest airflow-core/tests/unit/utils/test_db_cleanup.py -xvs (113 passed, 3 backend-specific skipped)
• env -u DOCKER_HOST DOCKER_CONTEXT=colima breeze run --backend postgres pytest airflow-core/tests/unit/utils/test_db_cleanup.py -xvs (115 passed, 1 MySQL-specific skipped)
• env -u DOCKER_HOST DOCKER_CONTEXT=colima breeze run --backend mysql pytest airflow-core/tests/unit/utils/test_db_cleanup.py -xvs (114 passed, 2 PostgreSQL-specific skipped)
• prek run --from-ref upstream/main --stage pre-commit (passed)
• prek run --from-ref upstream/main --stage manual --skip compile-ui-assets-dev --skip view-skill-eval --skip run-skill-eval-codex (passed)

---

Was generative AI tooling used to co-author this PR?

• Yes (Codex)

Generated-by: Codex following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

---

Drafted-by: Codex (no human review before posting)

[hussein-awala]

Good one, LGTM!

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test