Re: The planner chooses seqscan+sort when there is an
От | Csaba Nagy |
---|---|
Тема | Re: The planner chooses seqscan+sort when there is an |
Дата | |
Msg-id | 1146730172.14093.191.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: The planner chooses seqscan+sort when there is an (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: The planner chooses seqscan+sort when there is an
|
Список | pgsql-general |
> > 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... Well, I guess that's it then... I will let the query run with the seqscan+sort. It will still run 1-2 days, yesterday I stopped it after 6 hours ;-) Actually it would be nice to have some kind of feedback on what is it doing so I can estimate how long it will still take... cause I'm not sure the seqscan+sort won't run itself for 6 weeks... Thanks, Csaba.
В списке pgsql-general по дате отправления: