Cardinality estimation
The planner's guess at how many rows each step will produce. Everything else in the plan follows from it, which makes it the single most important number in the optimiser.
Join order, join method and index choice all rest on estimated row counts, and an error propagates multiplicatively up the join tree: a factor of ten wrong at the bottom can become a factor of a thousand at the top, and therefore a hash join where a nested loop would have taken milliseconds. The commonest sources of error are the planner assuming columns are independent when they are in fact correlated — postcode and city, product and category — plus expressions it cannot see through and statistics that were never refreshed. The countermeasures in PostgreSQL are CREATE STATISTICS for column combinations and raising the statistics target on skewed columns.