Fix N+1 queries in trigger asset event submission#65367
Open
henry3260 wants to merge 1 commit into
Open
Conversation
potiuk
added
the
ready for maintainer review
Contributor
Author
|
Hi @ashb Could I get your review when you get a chance? Thanks in advance! |
henry3260
force-pushed
the
fix-n-1-query-in-trigger
branch
from
953ac8e to
b476dbb
Compare
jason810496
reviewed
Jun 25, 2026
jason810496
left a comment
jason810496
left a comment
Member
There was a problem hiding this comment.
LGTM overall, I verify the select chain as well. Nice catch, left small nits regarding the test cases.
I will merge this for 3.3.1.
Comment on lines
+256
to
+267
| def _submit_event_query_count(trigger_id: int) -> int: | ||
| with count_queries(session=session) as query_result: | ||
| Trigger.submit_event(trigger_id, TriggerEvent("payload"), session=session) | ||
| return sum(query_result.values()) | ||
|
|
||
| small_query_count = _submit_event_query_count(_create_trigger_with_assets(1)) | ||
| larger_query_count = _submit_event_query_count(_create_trigger_with_assets(5)) | ||
|
|
||
| assert larger_query_count - small_query_count < 3, ( | ||
| f"Added 4 assets but query count increased by {larger_query_count - small_query_count} " | ||
| f"({small_query_count} -> {larger_query_count}), suggesting n+1 queries for trigger assets" | ||
| ) |
Member
There was a problem hiding this comment.
IIUC, we should parameterize the asset_count at test function level and get the exact same select count.
| def test_submit_event_no_n_plus_one_for_assets(_, session): | ||
| """Ensure asset notifications do not trigger per-asset lazy-load queries.""" | ||
|
|
||
| def _create_trigger_with_assets(asset_count: int) -> int: |
Member
There was a problem hiding this comment.
Then we could collapse the these utility function as the test function itself.
Member
There was a problem hiding this comment.
Yep, making it a nested function gives us limited gain here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
When a trigger submits an event for watched assets, Airflow needs to load the trigger's asset watchers and their related assets before registering asset changes. These relationships were previously loaded lazily, so a trigger watching multiple assets could issue extra queries per asset during event submission.
This adds unnecessary database overhead in the Triggerer path and can scale poorly for triggers that notify many assets. Loading the asset watcher graph up front keeps event submission query usage stable as the number of watched assets grows.
Was generative AI tooling used to co-author this PR?
{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.Important
🛠️ Maintainer triage note for @henry3260 · by
@potiuk· 2026-06-18 13:57 UTCPaused pending your next update — this PR has been inactive for ~41 days, so it's been moved to draft to keep the review queue clear:
main, address any new failures, and mark it Ready for review when you pick it back up — no rush.The ball is in your court — you've been assigned to this PR.
Automated triage — may be imperfect; a maintainer takes the next look.