Re: planner, *_collapse_limit

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Marcus Engene <mengpg2(at)engene(dot)se>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: planner, *_collapse_limit
Date: 2012-07-26 17:01:00
Message-ID: CAHyXU0wYES2QtdKdoNNuviJDm1PBugn3hUCE=xXXAEGZ9Ey7dQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Jul 26, 2012 at 9:42 AM, Marcus Engene <mengpg2(at)engene(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2012-07-27 00:25:54 Re: Linux memory zone reclaim
Previous Message Marcus Engene 2012-07-26 14:42:30 planner, *_collapse_limit