Re: fool-toleranced optimizer - Mailing list pgsql-hackers

From Greg Stark
Subject Re: fool-toleranced optimizer
Date
Msg-id 874qfk5f8b.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: fool-toleranced optimizer  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: fool-toleranced optimizer  (Kevin Brown <kevin@sysexperts.com>)
Re: fool-toleranced optimizer  (Richard Huxton <dev@archonet.com>)
List pgsql-hackers
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.

But outputing a warning and then continuing on to destroy performance just
gets the worst of both worlds.

For that matter, I wonder whether it's time to consider an option to disable
implicit (ie, pre-ansi join syntax) joins entirely. It seems like lots of
shops are likely imposing coding standards that require ansi join syntax
anyways. In environments like that you would expect "a CROSS JOIN b" not just
"select * from a,b" anyways. 

Shops like that might appreciate the ability to enforce a blanket coding
standard on that point and get protection from accidental cartesian joins as a
side benefit.

-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: We are not following the spec for HAVING without GROUP