The costs are there to choose a plan. Relative ordering (individually and in aggregate) is all that's really needed for this, rather than some function of time.

The costs are there to choose a plan. Relative ordering (individually and in aggregate) is all that's really needed for this, rather than some function of time. Actual run time is heavily dependent on distribution of data. There may be characteristics of your data not modelled in statistics used to calculate costs. If I were running a query that might take 15 minutes, I'd break it down, and put limit clauses in pinch points to figure out which bits of the query are sensitive (e.g. how much run time changes with increments to limits). But often just looking at the plan will tell me if the database is doing joins in the order I think would be more or less efficient, given the extra context I have on the data distribution.