I wrote:
> There is something funny going on there; it's not just that the planner
> is slower with a large flat search space. It is slower, but only maybe
> 5x or so. What I'm seeing is that it actually finds a much worse plan
> (very much larger estimated cost as well as actual runtime) when given
> the flat problem. That seems like a bug: a constrained search ought
> never find a better solution than an unconstrained search.
Oh, wait: the problem of course is that it's switching into GEQO mode
and hence *not* doing a complete search. Doh. If you turn GEQO off
then planning takes ~ forever with the flat version of the query.
We could "fix" that by forcibly breaking up the search problem in the
same fashion that join_collapse_limit does, but I'm sure we'd get
complaints about that approach.
The real fix in my mind is to replace GEQO search with something
smarter. I wonder what happened to the SA patch that was reported
on at PGCon.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
