Re: Problem with index not always being used

Thanks for the thoughts, certainly I will look into what you have explained.
However, the behavior that you expressed isn't what is occuring. In the 12,
16 example 12 does have more rows than 16. However, there are many cases
when this isn't true, that is other states have more rows than 12 and the
optomizer does use the index when I query them. There are 6 states total
that the optomizer doesn't use the index. The other 5 states would rank row
rise in the minority (of number rows) which would make me believe the
optomizer would want to use the index. That said I am investigating the
statistics and the random_page_cost.

Thank you for your insight.

Rob.

On 2/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Rob Tester" <robtester(at)gmail(dot)com> writes:
> > SELECT * FROM STUFF WHERE state=12; --causes a seq scan of the table
> > where
> > SELECT * FROM STUFF WHERE state=16 --Uses the index.
>
> This behavior is intended and appropriate, if there are lots of rows
> with state=12 and not many with state=16. As an example, if nearly the
> whole table had state=12 you would certainly not wish it to use an
> indexscan for that. The correct way to think about your gripe is that
> the planner's cutting over at the wrong row density. There are a couple
> of places to look for a solution:
>
> First, are the planner's estimated row counts for both cases reasonably
> close to reality, according to EXPLAIN ANALYZE? If not, you may need to
> increase the statistics target (either globally with
> default_statistics_target or for the state column with ALTER TABLE).
> Don't forget to re-ANALYZE the table after changing the target.
>
> If the statistics are good then you need to fool with the planner's cost
> parameters to get it to make decisions that reflect your environment.
> Decreasing random_page_cost is usually the thing to do if it's choosing
> seqscans too readily. But be wary of choosing a new value on the basis
> of just one test case.
>
> You can find a lot about this in the pgsql-performance list archives,
> and there are several relevant articles at techdocs:
> http://www.postgresql.org/docs/techdocs
>
> regards, tom lane
>