Re: *_collapse_limit, geqo_threshold

Joshua Tolley <eggyknap(at)gmail(dot)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