> > 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
