Django Query Plan Reading
Use this skill when the expensive unit is a specific SQL statement or queryset. The goal is to explain why the database is doing work, not to guess from the ORM code.
Workflow
Get the exact query.
- Prefer the queryset that produced it.
- If starting from logged SQL, include bound parameters or representative literals.
Generate a plan.
- Use
queryset.explain()for ORM-owned SQL. - Use database
EXPLAINfor raw SQL, views, materialized views, or SQL copied from logs. - Use
analyze=Trueonly in a safe environment because the database executes the query.
- Use
Read from the deepest node outward.
- Identify table scans, index scans, joins, sorts, aggregations, and limits.
- Compare estimated rows with actual rows when using analyze.
- Look for high-cost nodes that feed many rows to later nodes.
Decide the next change.
- Missing selective access path: use
django-index-design. - Query shape prevents useful index access: rewrite filters, ordering, or join strategy.
- Large unavoidable aggregation: consider
django-db-side-computationordjango-materialized-views. - Deep offset cost: use
django-pagination-performance.
- Missing selective access path: use
Re-run the same plan after the change.
- Compare scan type, row counts, sort nodes, heap fetches, buffers, planning time, and execution time.
See explain-checklist.md for plan-reading cues and before/after review notes.
Safety Notes
EXPLAIN ANALYZEexecutes the query. Avoid it for mutations, unsafe functions, and production paths unless you know the impact.- A sequential scan is not automatically bad. It can be best when the table is small or the predicate returns much of the table.
- A used index is not automatically good. Random heap access, bad cardinality estimates, or a post-index sort can still dominate.
Verification
Finish with the before/after plan excerpt and a plain explanation of which node changed and why that matters.
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/django-query-plan-reading/SKILL.md