Re: Mini improvement: statement_cost_limit

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
query rejection to be handled in a user-friendly way from the UI
("Search too complex. Try changing search terms.") rather than timing
out, which is very difficult to handle well.

The usefulness of this feature for interactive sessions is
limited-to-nonexistant. It's for production applications.

--Josh Berkus