Jonas

Three things to look at and ignore the rest is the right way in. Nobody needs the whole subject to answer this question.

For reading the plan without learning the whole subject, there are three things to look at and you can ignore the rest at first.

Run it with the option that actually executes the query rather than only estimating, and with buffers. That gives you real row counts alongside the estimates, which is where the answer usually is.

Then:

Compare estimated rows against actual rows at each node. If the planner estimated a hundred and got half a million, it made its decision on bad information and that is your problem: statistics, or a correlation between columns it cannot see.

Find where the time actually goes. The node with the largest actual time is the one to care about. People often optimise a node that accounts for two percent of the query.

Look at the filter line under the scan. It shows what the condition became after parsing, and this is where you catch the implicit cast or the function wrapping - you will literally see it in the plan text even though your query looked clean.

A useful trick when you suspect the planner is choosing wrongly: temporarily discourage sequential scans in your session and re-run. If it then uses the index and is faster, the index is fine and the planner made a bad cost decision. If it uses the index and is slower, the planner was right. Do not leave that setting on; it is a diagnostic, not a fix.