Re: Inefficient plan selected by PostgreSQL 9.0.7

Maxim Boguk <maxim.boguk@gmail.com> writes:
> I got very inefficient plan for a simple query.

It looks like the problem is with the estimate of the antijoin size:

>          ->  Nested Loop Anti Join  (cost=0.00..24576.82 rows=1 width=206)
> (actual time=0.043..436.386 rows=20761 loops=1)

that is, only about 20% of the rows in sb_messages are eliminated by the
NOT EXISTS condition, but the planner thinks that nearly all of them
will be (and that causes it to not think that the LIMIT is going to
affect anything, so it doesn't prefer a fast-start plan).

Since you've not told us anything about the statistics of these tables,
it's hard to speculate as to why the estimate is off.

            regards, tom lane