Re: index vs. seq scan choice?
От | George Pavlov |
---|---|
Тема | Re: index vs. seq scan choice? |
Дата | |
Msg-id | 8C5B026B51B6854CBE88121DBF097A86DEA6D3@ehost010-33.exch010.intermedia.net обсуждение исходный текст |
Ответ на | Re: index vs. seq scan choice? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: index vs. seq scan choice?
|
Список | pgsql-general |
> From: Tom Lane > "George Pavlov" <gpavlov@mynewplace.com> writes: > >> From: Joshua D. Drake [mailto:jd@commandprompt.com] > >> In those rare cases wouldn't it make more sense to just set > >> enable_seqscan to off; run query; set enable_seqscan to on; > > > 1. these cases are not that rare (to me); > > It strikes me that you probably need to adjust the planner cost > parameters to reflect reality on your system. Usually dropping > random_page_cost is the way to bias the thing more in favor of > index scans. Thanks, Tom, I will try that. Seems better than fiddling with enable_seqscan around every query/transaction. Joshua, I fail to understand why setting and unsetting enable_seqscan on a per query/transaction basis is in any way preferable to query hints? Don't get me wrong, I don't like the idea of hints, and I have read the archives on the subject and I agree with the philosophy, but if the optimization toolkit for routine application queries is going to include setting config parameters that just smacks of hints by another name... George
В списке pgsql-general по дате отправления: