| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | 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-04 20:49:43 |
| Message-ID: | 1217882983.3934.548.camel@ebony.t-mobile.de. |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Sure, its an estimate, but it's got to be a based upon an estimate if it
acts *before* it runs. And surely there is no better estimate of the
cost than the plan cost?
It doesn't stop anyone from putting in resource limits, later.
We'll have to do something with enable_seqscan, BTW, chaps.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2008-08-04 20:53:59 | Re: Mini improvement: statement_cost_limit |
| Previous Message | Kevin Grittner | 2008-08-04 20:07:30 | Re: Mini improvement: statement_cost_limit |