pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedplanner, *_collapse_limit
2+ messages / 2 participants
[nested] [flat]
* planner, *_collapse_limit
@ 2012-07-26 14:42 Marcus Engene <mengpg2@engene.se>
0 siblings, 1 reply; 2+ messages in thread
From: Marcus Engene @ 2012-07-26 14:42 UTC (permalink / raw)
To: pgsql-performance
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.
Best regards,
Marcus
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: planner, *_collapse_limit
@ 2012-07-26 17:01 Merlin Moncure <mmoncure@gmail.com>
parent: Marcus Engene <mengpg2@engene.se>
0 siblings, 0 replies; 2+ messages in thread
From: Merlin Moncure @ 2012-07-26 17:01 UTC (permalink / raw)
To: Marcus Engene <mengpg2@engene.se>; +Cc: 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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2012-07-26 17:01 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-07-26 14:42 planner, *_collapse_limit Marcus Engene <mengpg2@engene.se>
2012-07-26 17:01 ` Merlin Moncure <mmoncure@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox