Re: Mini improvement: statement_cost_limit

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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +