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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
