Re: Mini improvement: statement_cost_limit

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 a
> winner. Even the person who submitted the stupid query, since they
> find
> out 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 decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828