Hi,
Le 3 avr. 09 à 22:29, Tom Lane a écrit :
Correct, but you've got the details all wrong. The real problem is
that
the planner might discard a join path hash(A,B) at level 2 because it
loses compared to, say, merge(A,B). But when we get to level three,
perhaps hash(hash(A,B),C) would've been the best plan due to synergy
of the two hashes. We'll never find that out unless we keep the
"inferior" hash path around. We can certainly do that; the question
is what's it going to cost us to allow more paths to survive to the
next join level. (And I'm afraid the answer may be "plenty"; it's a
combinatorial explosion we're looking at here.)
I remember having done some board game simulation project at school,
using alpha-beta algorithms with cuts, and as an optimisation a
minimax too. Those are heuristics, but that you can decide to run on
the full set of possible trees when you want a global optimum rather
than a local one.
Now, I don't know the specifics of the planner code, but would it be
possible to use a minimax kind of heuristic? Then a planner effort GUC
would allow users to choose whether they want to risk the "plenty"
combinatorial explosion in some requests.
It could be that the planner already is smarter than this of course,
and I can't even say I'd be surprised about it, but still trying...
--
dim
http://en.wikipedia.org/wiki/Minimax
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
