Re: planner, *_collapse_limit

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: planner, *_collapse_limit
Дата
Msg-id CAHyXU0wYES2QtdKdoNNuviJDm1PBugn3hUCE=xXXAEGZ9Ey7dQ@mail.gmail.com
обсуждение исходный текст
Ответ на planner, *_collapse_limit  (Marcus Engene <mengpg2@engene.se>)
Список pgsql-performance
On Thu, Jul 26, 2012 at 9:42 AM, Marcus Engene <mengpg2@engene.se> wrote:
> Hi,
>
> I've read a little bit about join_collapse_limit and from_collapse_limit and
> I see their reason to exist.
>
> A stupid question: in algorithms 101 you're usually told to make a chess
> program and then you usually do a width first min max tree. A low level
> opponent would interrupt this possibly infinite traversal early, thus
> returning a possibly bad move, and if it's on a higher level it's allowed to
> work longer and it will likely present a better path in the tree.
>
> I understood it as that the *_collapse_limits are to stop a worst case join
> making the optimizer going haywire, but it feels sad that trivial big joins
> are cut off even if they're not too nasty.
>
> Why would it not make some sense to have some time/space constraint on the
> join heuristics instead of/in combination to how the limit presently work?
> If we hit the ceiling, the best produced plan so far is used. The chess
> analogy would obviously be a handful chess pieces left but the min-max-tree
> traversal constraint is on a low depth (rather than time/memory) so it would
> quickly traverse the few options and then be constrained.

Well, isn't it the point of the genetic optimizer to solve exactly
that problem?   I do find it interesting though that there is a window
between collapse limit and geqo.

merlin

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

Предыдущее
От: Marcus Engene
Дата:
Сообщение: planner, *_collapse_limit
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Linux memory zone reclaim