Re: *_collapse_limit, geqo_threshold

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: *_collapse_limit, geqo_threshold
Дата
Msg-id 4A5733ED02000025000286A0@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: *_collapse_limit, geqo_threshold  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote: 
> At any rate the particular choice of keyword seems rather  
> insignificant; I picked it because it was already a keyword and
> seemed vaguely appropriate, but it could easily be changed.
Actually, if we were going to add fine-grained optimizer hints for
this (which I'm not at all convinced is a good idea), I'd be tempted
to go with what I saw a few years ago in SAP-DB (later rebranded as
MySQL Max-DB): treat parentheses around JOIN operations as optimizer
hints.  I would only consider this as remotely sane if there was an
enable_* GUC to disable the normal reordering of joins.  It introduces
no new keywords.  The queries are still standard compliant.  We would
just have a configuration option which treats an optional part of the
standard syntax as a hint.
In other words:
select * from (t1 join t2 on <whatever>) join t3 on <whatever>;
would limit optimizer choice from those available with:
select * from t1 join t2 on <whatever> join t3 on <whatever>;
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: Lock Wait Statistics (next commitfest)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: *_collapse_limit, geqo_threshold