From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Mark Wong <markwkm(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: parallelizing subplan execution (was: explain and PARAM_EXEC) |
Date: | 2010-06-27 12:01:05 |
Message-ID: | 1277640065.25074.56724.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron W. Swenson | 2010-06-27 12:13:19 | Why are these modules built without respecting my LDFLAGS? |
Previous Message | Simon Riggs | 2010-06-27 11:52:17 | Re: GSoC - code of implementation of materialized views |