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
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 |