Kevin Brown <[EMAIL PROTECTED]> writes:
Hence, it makes sense to go ahead and run the query, but issue a warning at the very beginning, e.g. "WARNING: query JOINs tables <list of tables> without otherwise referencing or making use of those tables. This may cause excessively poor performance of the query".
Well the problem with a warning is what if it *is* intentional? It's not ok to fill my logs up with warnings for every time the query is executed. That just forces me to turn off warnings.
It would be ok to have an option to block cartesian joins entirely. I might even choose to run with that enabled normally. I can always disable it for queries I know need cartesion joins.
I'm not sure the cartesian join is the problem - it's the explosion in number of rows. Which suggests you want something analogous to statement_timeout. Perhaps something like:
statement_max_select_rows = 0 # 0=disabled
statement_max_update_rows = 0 # applies to insert/delete too
That has the bonus of letting you set statement_max_update_rows=1 in an interactive session and catching WHERE clause typos.
On the down-side, it means 2 more GUC variables and I'm not sure how practical/efficient it is to detect a resultset growing beyond that size.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
