On Sat, 2010-06-26 at 21:01 -0400, Robert Haas wrote:
> The section (from that same paper) on parallelizing hash joins and
> merge-join-over-sort is interesting, and I can definitely imagine
> those techniques being a win for us. But I'm not too sure how we'd
> know when to apply them - that is, what algorithm would the query
> optimizer use? I'm sure we could come up with something, but I'd get
> a warmer, fuzzier feeling if we could implement the fruits of someone
> else's research rather than rolling our own.
You've just touched on why parallel query is hard. There is a big bucket
of executor code to write and then lots of very subtle thinking,
heuristics and usability parameters to make parallel query sensibly
optimised. You need both to make it actually work in practice (without
hints).
Parallel sub-plans is not a good case to start with because it presumes
only certain kinds of plans are in place. It wouldn't be usable for the
majority of plans.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
