Optimize a measured reader task ​

Begin with a correct representative query and a clear result requirement. Keep the data, parameters, output format and row limits fixed when comparing a change. A query that omits required rows has not improved the original task.

Inspect its access plan:

EXPLAIN QUERY PLAN
SELECT id, amount
FROM orders
WHERE account_id = 42
ORDER BY id
LIMIT 20;

Check whether a targeted index matches the repeated lookup. Consider the effect on writes before adding several indexes. Restrict the projected columns and validate joins for accidental row multiplication before tuning resource ceilings.

For each measured execution, retain the query ID and terminal duration, read work, result count and peak accounted memory. Repeat only enough to understand ordinary variation; a single unusually fast run is weak evidence. EXPLAIN ANALYZE is useful for runtime measurements but executes the statement once, including writes.

max_threads is a ceiling for eligible queries, not a promise of parallel execution. Raising it or a memory limit does not by itself reduce work. Keep the change that helps the actual reader workload and document the observed scope.

See query measurements, indexes and max_threads.