Previous module: Module 12, Checking whether your result is right.
A slow query doesn’t always need another index. Before changing anything, we need to understand how PostgreSQL reads the table and how many rows the filter keeps.
For example, a tracking-code lookup returns one row from 30,000 orders. An index is useful in this case because the filter is very selective. A status filter that keeps 24,000 rows is different because PostgreSQL still needs most of the table.
For me, query optimization starts after the result is correct. We should read the plan, change one thing, and confirm that the query still returns the same result.
We will compare a sequential scan with an index scan, then check why PostgreSQL can still choose a sequential scan when an index exists.
