Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever - Mailing list pgsql-bugs

From Michael Fuhr
Subject Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Date
Msg-id 20050116204814.GA82738@winnie.fuhr.org
Whole thread Raw
In response to Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
List pgsql-bugs
On Sun, Jan 16, 2005 at 02:56:11PM -0500, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.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/

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Next
From: "Luiz Gonzaga da Mata"
Date:
Subject: Re: Bug in check constraint?