On Thu, Dec 08, 2005 at 01:07:10PM -0500, Tom Lane wrote: > Jaime Casanova <[EMAIL PROTECTED]> writes: > >> BTW, there's another end to the 'enable_seqscan=false' problem... it > >> sometimes doesn't work! > > > I have often considered that this is an indication that seq scan is > > actually the better plan... > > There are cases where it is the *only* plan, eg, you have no relevant > indexes. I am not sure that applies to Jim's complaint though.
IIRC I ran into this when I was working on generating some numbers about how well a high correlation improves the performance of an index scan (since afaict the cost estimator for index scan is rather broken :( ) In that case, I had defined an index on a ~120M row table on a collumn with a very low correlation. It's pretty much a given that a seqscan and sort would be faster than the index scan, but it would have still been good to be able to verify that. Because of how enable_seqscan works, I couldn't. BTW, http://archives.postgresql.org/pgsql-performance/2005-04/msg00669.php is where I first mentioned this, including the cost function that I think is broken. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
