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
|
Список | 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 по дате отправления: