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
|
Список | 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 по дате отправления: