Re: Mini improvement: statement_cost_limit

From: Decibel! <decibel(at)decibel(dot)org>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, daveg <daveg(at)sonic(dot)net>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Mini improvement: statement_cost_limit
Date: 2008-08-11 16:47:10
Message-ID: A8D6C6BF-8984-414B-9813-341D37C9CFEA@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-08-11 16:59:27 Re: IN vs EXISTS equivalence
Previous Message Decibel! 2008-08-11 16:37:16 Re: Mini improvement: statement_cost_limit