On Aug 4, 2008, at 3:49 PM, Simon Riggs wrote:
On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:On Monday 04 August 2008 03:50:40 daveg wrote:And you'll note, I specifically said that a crude tool is better than nothing. But your completely ignoring that a crude tool can often end-up as a foot-gun once relased into the wild.The proposal is for an option with no consequences when turned off. We respect your right not to use it. What is the danger exactly? If we cancel stupid queries before people run them, everybody is awinner. Even the person who submitted the stupid query, since they findout faster.
I could *really* use this. Unfortunately, we have a lot of folks writing some horrible queries and killing our slave databases. I'd *love* to be able to throw out any queries that had insane limits...
We'll have to do something with enable_seqscan, BTW, chaps.
My thought would be to back the cost penalty out if we end up with a seqscan anyway.
Speaking of which, there is a semi-related issue... if you have a large enough table the fixed-size cost we add to a seqscan won't be enough to make an alternative plan come out cheaper. Instead of adding a fixed cost, I think we should multiply by the estimated number of rows.
-- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828
smime.p7s
Description: S/MIME cryptographic signature
