Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output

I have postgresql 8.4.15 on Ubuntu 10.04 and this query:

    SELECT MAX(probeTable.PROBE_ALARM_EVENT_ID) AS MAX_EVENT_ID
    FROM ALARM_EVENT eventTable
    INNER JOIN ALARM_EVENT_PROBE probeTable
       ON eventTable.ALARM_EVENT_ID = probeTable.ALARM_EVENT_ID
    WHERE probeTable.PROBE_ID = 2

which is running slower than it could. Table definitions and explain
analyze output below.
The first explain is the current plan (uses sequential scans).
The second is after I have disabled sequential scans, and is the plan
I would prefer.

I have vacuum analyzed both tables. In terms of relevant changes to
the default postgresql.conf, we have these:

    shared_buffers = 28MB
    constraint_exclusion = on

I want to understand why the optimiser is choosing the plan with
sequential table scans, rather than the plan with index scans.
I am not sure how to interpret the predicted vs actual times/costs,
and want to understand why the predicted cost for the index scan plan
seems to be way off.