Greg Stark wrote:
> Kevin Brown <kevin@sysexperts.com> 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
