From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Solving sudoku using SQL |
Date: | 2010-12-08 17:45:45 |
Message-ID: | 17547.1291830345@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2010-12-08 18:02:35 | Re: Solving sudoku using SQL |
Previous Message | Tom Lane | 2010-12-08 17:31:47 | Re: Solving sudoku using SQL |