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.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers