Re: Index not being used unless enable_seqscan=false
| От | Shane |
|---|---|
| Тема | Re: Index not being used unless enable_seqscan=false |
| Дата | |
| Msg-id | 20050810203159.GA7255@cm.nu обсуждение исходный текст |
| Ответ на | Re: Index not being used unless enable_seqscan=false (Sven Willenberger <sven@dmv.com>) |
| Ответы |
Re: Index not being used unless enable_seqscan=false
|
| Список | pgsql-general |
On Wed, Aug 10, 2005 at 04:24:51PM -0400, Sven Willenberger wrote: > On Wed, 2005-08-10 at 12:58 -0700, Shane wrote: > > On Wed, Aug 10, 2005 at 03:31:27PM -0400, Sven Willenberger wrote: > > > Right off the bat (if I am interpreting the results of your explain > > > analyze correctly) it looks like the planner is basing its decision to > > > seqscan as it thinks that it needs to filter over 1 million rows (versus > > > the 29,000 rows that actually are pulled). Perhaps increasing stats on > > > msgtime and then analyzing the table may help. Depending on your > > > hardware, decreasing random_page_cost in your postgresql.conf just a > > > touch may help too. > > Try increasing stats to 100 on just the msgtime column, not the default > (changing the default will only have an effect on newly created columns > -- you may want to change the default back to 10): Hi, I brought the statistics on msgtime up to 100, vacuum analyzed and brought random_page_cost down to 2. Unfortunately, explain analyze still wants to seqscan and estimates 1m returned rows. Is there a way to simply force an index usage for this particular query? S
В списке pgsql-general по дате отправления: