From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
Subject: | Re: Mini improvement: statement_cost_limit |
Date: | 2008-08-15 15:16:23 |
Message-ID: | 200808151516.m7FFGNR19260@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus wrote:
> Greg,
>
> > Well that's going to depend on the application.... But I suppose there's
> > nothing wrong with having options which aren't always a good idea to use. The
> > real question I guess is whether there's ever a situation where it would be a
> > good idea to use this. I'm not 100% sure.
>
> I can think of *lots*. Primarily, simple web applications, where
> queries are never supposed to take more than 50ms. If a query turns up
> with an estimated cost of 10000000000, then you know something's wrong;
> in the statistics if not in the query. In either case, that query has a
> good chance of dragging down the whole system.
>
> In such a production application, it is better to have false positives
> and reject otherwise-OK queries becuase their costing is wrong, than to
> let a single cartesian join bog down an application serving 5000
> simultaneous users. Further, with a SQL error, this would allow the
How about a simpler approach that throws an error or warning for
cartesian products? That seems fool-proof.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2008-08-15 15:47:07 | Re: Mini improvement: statement_cost_limit |
Previous Message | Tom Lane | 2008-08-15 15:14:40 | Re: So what about XSLT? |