Re: fool-toleranced optimizer

Greg Stark wrote:
> Kevin Brown <kevin(at)sysexperts(dot)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