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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
