hkc-8010 commented on PR #73911: URL: https://github.com/apache/airflow/pull/73911#issuecomment-6009619676
Production corroboration for #72393, from a customer escalation on Airflow 3.3.1. A deployment with ~3,900 DAG rows reaching `find_orm_dags`: the database side is fine at ~16ms, but the cartesian product across the five eager-joined one-to-many collections turns that into 10–19s of client-side row deserialization per sync. The DAG processor spends its cycle there, which was one half of a two-part failure we spent an incident on. On the diff itself: the five `joinedload` → `selectinload` swaps look right and the `with_row_locks(..., of=DagModel)` wrapper is untouched. Worth noting explicitly for reviewers, since it is the one thing that looks like it might change semantics: because the lock was already scoped `of=DagModel`, the one-to-many rows were never locked under `joinedload` either, so moving them into separate SELECTs changes no locking behaviour. `joinedload(DagModel.tags, innerjoin=False)` → `selectinload(DagModel.tags)` is likewise a no-op on outer-join semantics. @seanmuth's #72395 was the original work and was closed in the open-PR-limit cull rather than on merit, as noted above. One procedural thing: this PR appears to have only the Mergeable and WIP app checks on 4edd569, with no Airflow CI workflows run at all. If a committer could approve the workflow runs, that would unblock it. -- 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]
