Re: fool-toleranced optimizer

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: fool-toleranced optimizer
Date: 2005-03-10 03:53:08
Message-ID: 874qfk5f8b.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-03-10 04:00:26 Re: We are not following the spec for HAVING without GROUP
Previous Message Bruce Momjian 2005-03-10 03:51:27 Re: [pgsql-hackers-win32] snprintf causes regression tests