Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever

On Sun, Jan 16, 2005 at 02:56:11PM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
>
> > Maybe I don't understand something about what EXPLAIN is showing,
> > but why does Limit have an estimated cost of 0.00..25.79 when the
> > thing it's limiting has a cost of 0.00..2552.75?
>
> This represents the planner assuming that the indexscan will only need
> to be run 1/99th of the way to completion.

Thanks -- I understood the rationale for considering a scan on this
index but not why that plan was preferred. Your explanation provides
the piece I was missing.

> Basically, what you're looking at here is that the planner is thinking
> it should go for a fast-start plan in a scenario where that bet loses.
> It's still a good bet though. I'm not sure how to formulate the notion
> that there's too much risk of a slow result in this scenario.

Would it be accurate to say that the planner makes the bet most
likely to win without regard to how badly it might lose? Is taking
the downside into consideration a tough problem to solve, or is it
simply not worthwhile in the large?

Thanks again.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/