Re: The planner chooses seqscan+sort when there is an
| От | Scott Marlowe |
|---|---|
| Тема | Re: The planner chooses seqscan+sort when there is an |
| Дата | |
| Msg-id | 1146681396.22037.42.camel@state.g2switchworks.com обсуждение исходный текст |
| Ответ на | Re: The planner chooses seqscan+sort when there is an (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: The planner chooses seqscan+sort when there is an
|
| Список | pgsql-general |
On Wed, 2006-05-03 at 13:34, Tom Lane wrote: > Csaba Nagy <nagy@ecircle-ag.com> writes: > > OK, maybe that's the point... the "cost bust" given to the sequential > > scan by enable_seqscan=off is not enough in this case to exceed the cost > > of the index scan ? > > Looks that way to me. You could try setting enable_sort off as well, > which will penalize the seqscan+sort plan another 100million cost units. > And maybe try reducing random_page_cost to make the indexscan look > cheaper. However, if there's a 100million delta between the two plans, > I suspect you really really don't want the indexscan anyway ;-) I imagine the followup post: So, I've had this query running for six weeks now, and...
В списке pgsql-general по дате отправления: