Re: fool-toleranced optimizer

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