Read an execution plan before adding another index
A slow query is reported and someone proposes an index on every filtered column. More indexes increase storage and write work, and separate indexes do not necessarily support the query as well as a deliberate composite index.
Capture the query and plan together
EXPLAIN
SELECT id, created_at
FROM orders
WHERE tenant_id = 42
ORDER BY created_at DESC, id DESC
LIMIT 30;
Use representative parameters and data distribution. Inspect the chosen access path, estimated rows, and sorting behavior. A plan from an almost-empty development table is not reliable evidence for a large production table.
Estimates and execution are different evidence
EXPLAIN ANALYZE executes supported statements to collect actual timing and row information. Do not casually run an expensive production query merely because the command begins with EXPLAIN. Start with a safe environment and understand what the chosen form executes.
Compare the proposed index against existing indexes and the application's write workload. An index useful to one report can be unnecessary duplication or costly on a heavily written table.
Record before-and-after plans and measured behavior for the same fixture or workload. Avoid declaring a universal speedup based on one warm-cache run. If the plan still scans many rows, inspect whether the predicate, ordering, or selected result size is the real constraint. An index is a hypothesis to verify, not a certificate that a query is optimized.