>
> Check the estimated number of rows returned. It's presumably believing
> that the a sequential scan will be cheaper for the estimated number of
> rows.
>
> If the estimated number of rows is significantly off, you may wish to
> change the statistics target (see ALTER TABLE) for col1 and analyze the
> table again.
>
> If it still is choosing a sequential scan over an index scan and the
> number of rows is similar, you may want to look at the "random_page_cost"
> variable. You have to be careful not too lower it too far that other
> queries are pessimized the other direction, but some experimentation
> comparing the real times and estimated costs of queries with and without
> enable_seqscan=off may help.
Thanks for the detailed response! Your suggestion was spot-on.
Regards
Henry
--------------------------------------------------------
This message was sent using MetroWEB's AirMail service.
http://www.metroweb.co.za/ - full access for only R73.
Free Web Accelerator, WebMail, Calendar, Anti-Virus,
Anti-Spam, 10 emails, 100MB personal webspace, and more!
Phone Now! 086 11 11 440
