A sales dashboard that worked with six months of orders can stall when it has several years to search. Before adding indexes or buying a larger server, measure the report with the filters your staff actually use. A narrow branch view and a year-end export may need different plans.

Locate the slow part

Record the report parameters, response time and time spent in the database. Compare the query with the work the application does after retrieval, including formatting and export. A fast database query followed by a long spreadsheet export calls for a different fix. Use synthetic or appropriately protected data with a representative distribution of branches, customers and dates.

Read the plan before changing it

PostgreSQL’s EXPLAIN shows the planner’s estimated route. Estimated cost is a planning unit rather than elapsed milliseconds. EXPLAIN ANALYZE executes the statement and reports observed activity, so use a controlled environment for expensive queries and avoid running it on write statements during a routine investigation. Compare estimated and observed row counts around joins and filters. Large differences can suggest that planner statistics or assumptions deserve a closer look.

Test an index against real usage

Suppose staff typically filter orders to one branch and a short date range. Test whether an index that supports those conditions helps that query on representative data. Run the broad export too. A sequential scan may remain appropriate when a report needs much of a table. Include the cost of maintaining the proposed index during inserts and updates, and check deployment impact before approving a production change.

Make the result repeatable

Record the query shape, filter values, dataset size, plan and before-and-after timing. Repeat enough runs to distinguish a cache effect from a consistent improvement. Keep a broad and narrow report in the release checks and confirm both produce the same totals before and after the change. If results depend strongly on the branch or date range, preserve those cases in the handover.

For help with this review, see Software Maintenance or Review Your Slow Database Report.

Related reading includes handling concurrent edits and database transaction boundaries.

Review Your Slow Database Report

Bring one slow report, its usual filters and a timing sample. ITZ can help scope the review and agree a controlled test. Review Your Slow Database Report.

Original concept illustration. Primary documentation reviewed on 9 November 2026. Technical reference.