Define the output before reading SQL
Define revenue, timestamp choice, cancellations and the grain of one output row before inspecting a monthly-sales query. Is each row a day, product or customer? Prepare a small synthetic dataset with manually calculable expected results. This lets you review the answer rather than the apparent sophistication of the SQL. Correct column names and types are insufficient when the business definition is wrong. Keep the expected table beside the proposed query so that later optimization cannot silently change the meaning of the result.
Inspect join cardinality
An order-to-line-item join can create multiple rows per order, making an order-level amount unsafe to sum without considering duplication. Review the join keys and expected relationship. Decide whether records lacking a related row should remain, rather than automatically choosing an inner join. Include an order with two items, one missing relationship and separate records sharing a display name in the fixture. More rows are not necessarily better coverage. Verify the intended uniqueness at each stage before trusting an aggregate built on top of the join.
Check nulls and boundaries
Filtering out nulls and treating them as zero produce different answers. Review month boundaries, time zones and boundary timestamps, and avoid ambiguous date handling. For pagination, consider deterministic ordering when multiple rows share the same sort value. Expand fixtures by meaningful conditions rather than merely generating more random rows: just before, exactly at and just after a boundary can expose an interpretation error. These checks should happen before measuring speed, because a faster query that omits the required rows is not an improvement.
Preserve the authorized data boundary
A result obtained through an administrator connection does not establish that an ordinary user should receive it. Review tenant or user scope, execution role and returned columns. Avoid collecting unnecessary email addresses or internal notes merely because selecting every column is convenient. Do not fix an access error by switching to a stronger connection without reviewing the intended boundary. Verify the query under the relevant role and include permitted and excluded records in the expected result. Authorization is part of correctness, not a separate optimization to postpone.
Inspect the shape of the plan
PostgreSQL EXPLAIN shows the plan chosen by the planner. Inspect scans, joins, filters and sorts to understand the work proposed. Estimated cost is not a measured number of milliseconds. A sequential scan on a small relation is not automatically a defect; interpret it with data size and selectivity. An index also affects storage and writes, so do not turn one plan line into an immediate production schema change. Review the need and verification path for an index as a separate, inspectable intervention.
Distinguish planning from execution
EXPLAIN ANALYZE executes the statement to collect measurements, unlike an ordinary planning inspection. Confirm environment and effects before using it, especially for mutations or expensive work. Prefer an appropriate evaluation environment and record data size and query conditions for comparisons. Cache state, statistics and concurrent activity can influence results, so one faster run does not establish a universal performance advantage. Separate what the plan estimates, what an execution measured and what remains a hypothesis about a larger workload.
Keep the accepted query and expected results
Keep the output definition, synthetic fixture, expected rows, tested role and relevant plan with the accepted SQL. Recheck the same expected results after a performance rewrite. Do not include untested production volumes or access roles under an unqualified verification label. A maintainer should be able to reproduce the reasoning from the small fixture without the original assistant conversation. If the investigation reveals a need for schema changes, move to a migration and recovery plan rather than allowing a query-review task to expand silently into a production database alteration.
Official sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- PostgreSQL: Using EXPLAINInformation checked: 2026-10-29
- GitHub Docs: Reviewing pull requestsInformation checked: 2026-10-29
- Claude Code overviewInformation checked: 2026-10-27
- Claude Code costsInformation checked: 2026-10-27
- Claude Code permissionsInformation checked: 2026-10-27
- Cursor pricingInformation checked: 2026-10-26
- Cursor models and pricingInformation checked: 2026-10-26
- Cursor Agent overviewInformation checked: 2026-10-26
- GitHub Copilot plansInformation checked: 2026-10-26
- Plans for GitHub CopilotInformation checked: 2026-10-26
- GitHub Copilot overviewInformation checked: 2026-10-26