Re: Solving sudoku using SQL

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