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

Поиск
Список
Период
Сортировка
От Michael Fuhr
Тема Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Дата
Msg-id 20050116204814.GA82738@winnie.fuhr.org
обсуждение исходный текст
Ответ на Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Следующее
От: "Luiz Gonzaga da Mata"
Дата:
Сообщение: Re: Bug in check constraint?