Re: index scan of whole table, can't see why
От | Ragnar Hafstað |
---|---|
Тема | Re: index scan of whole table, can't see why |
Дата | |
Msg-id | 1106213669.22416.17.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | index scan of whole table, can't see why ("Dan Langille" <dan@langille.org>) |
Ответы |
Re: index scan of whole table, can't see why
|
Список | pgsql-performance |
On Wed, 2005-01-19 at 20:37 -0500, Dan Langille wrote: > Hi folks, > > Running on 7.4.2, recently vacuum analysed the three tables in > question. > > The query plan in question changes dramatically when a WHERE clause > changes from ports.broken to ports.deprecated. I don't see why. > Well, I do see why: a sequential scan of a 130,000 rows. The query > goes from 13ms to 1100ms because the of this. The full plans are at > http://rafb.net/paste/results/v8ccvQ54.html > > I have tried some tuning by: > > set effective_cache_size to 4000, was 1000 > set random_page_cost to 1, was 4 > > The resulting plan changes, but no speed improvment, are at > http://rafb.net/paste/results/rV8khJ18.html > this just confirms that an indexscan is not always better than a tablescan. by setting random_page_cost to 1, you deceiving the planner into thinking that the indexscan is almost as effective as a tablescan. > Any suggestions please? did you try to increase sort_mem ? gnari
В списке pgsql-performance по дате отправления: