Re: *_collapse_limit, geqo_threshold - Mailing list pgsql-hackers

From Tom Lane
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 17541.1247107387@sss.pgh.pa.us
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Joshua Tolley <eggyknap@gmail.com>)
List pgsql-hackers
Joshua Tolley <eggyknap@gmail.com> writes:
> This sounds like planner hints to me. The argument against hinting, AIUI, is
> that although the plan you've guaranteed via hints may be a good one today,
> when the data change a bit your carefully crafted plan happens to become a bad
> one, but you're no longer around to change the hints accordingly.

That's one argument against them.  Another one is that time put into
developing a planner hints mechanism is time that would be better spent
on fixing the underlying planner problem.  However, that second argument
doesn't apply to something like join_collapse_limit, whose
implementation is pretty nearly a one-liner (as are the various existing
enable_whatever switches).  Again, it's all about cost/benefit ratio.

> Do we know that GEQO plans are, in reality, less stable than than usual
> planner?

Yes, we do.  There aren't that many examples in the archives, but that
likely is because join_collapse_limit and from_collapse_limit are by
default set to try to prevent use of GEQO.  The most recent clear-cut
example I can find is
http://archives.postgresql.org/pgsql-general/2008-10/msg01449.php
wherein the guy has apparently written a "flat" FROM of 17 tables,
and so neither collapse_limit will kick in.  If we get rid of the
collapse_limits as proposed in this thread, you'll start seeing
those sorts of complaints all over the place, unless we make
GEQO deterministic.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joshua Tolley
Date:
Subject: Re: *_collapse_limit, geqo_threshold
Next
From: Tom Lane
Date:
Subject: Re: *_collapse_limit, geqo_threshold