On Thu, Dec 01, 2005 at 12:32:12PM -0500, Qingqing Zhou wrote: > > "Neil Conway" <[EMAIL PROTECTED]> wrote > > > > This would also be useful when diagnosing bad query plans: for example, > > setting enable_seqscan=false often causes the planner to disregard the > > use of *any* sequential scan, anywhere in the plan. The ability to > > slightly bump up the cost of particular operations would allow more > > alternative plans to be examined. > > > > This method also has the problem of "enable_seqscan=false" in some > situations. I would vote we implement the final general solution like query > plan hints directly.
BTW, there's another end to the 'enable_seqscan=false' problem... it sometimes doesn't work! Last I looked, enable_seqscan=false only added a fixed overhead cost to a seqscan (1000000 IIRC). The problem is, some queries will produce estimates for other methodes that are more expensive than a seqscan even with the added burden. If instead of adding a fixed amount enable_seqscan=false multiplied by some amount then this would probably be impossible to occur. (And before someone asks, no, I don't remember which query was actually faster...) -- 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 2: Don't 'kill -9' the postmaster
