Re: fool-toleranced optimizer

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: fool-toleranced optimizer
Дата
Msg-id 874qfk5f8b.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: fool-toleranced optimizer  (Kevin Brown <kevin@sysexperts.com>)
Ответы Re: fool-toleranced optimizer
Re: fool-toleranced optimizer
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [pgsql-hackers-win32] snprintf causes regression tests
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: We are not following the spec for HAVING without GROUP