Re: Index not being used unless enable_seqscan=false - Mailing list pgsql-general

From Shane
Subject Re: Index not being used unless enable_seqscan=false
Date
Msg-id 20050810203159.GA7255@cm.nu
Whole thread Raw
In response to Re: Index not being used unless enable_seqscan=false  (Sven Willenberger <sven@dmv.com>)
Responses Re: Index not being used unless enable_seqscan=false  (Sven Willenberger <sven@dmv.com>)
List 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 by date:

Previous
From: Dan Armbrust
Date:
Subject: Re: 5 new entries for FAQ
Next
From: Greg Stark
Date:
Subject: Re: escape string type for upcoming 8.1