Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Feb 20, 2010 at 6:57 AM, Dimitri Fontaine
>> Ok that's a far stretch from the question at hand, but would that be a
>> plausible approach to have parallel queries in PostgreSQL�?
> This is really a topic for another thread, but at 100,000 feet it
> seems to me that the hardest question is - how will you decide which
> operations to parallelize in the first place? Actually making it
> happen is really hard, too, of course, but even to get that that point
> you have to have some model for what types of operations it makes
> sense to parallelize and how you're going to decide when it's a win.
Indeed, and if I were setting out to parallelize queries in PG (which
I am not), subplans would be the last thing I would think about. You
could put an enormous amount of work in there and have nothing much
to show for it, because the construct doesn't even arise in many
queries. Even where the user wrote something that looks like a subplan,
the planner will do its best to get rid of it by turning it into a join.
So if you want to parallelize queries, start someplace else. The past
discussions of this have revolved around splitting the node tree of an
ordinary query plan into separately executable parts. Maybe a subplan
could be one of the cut points for such an approach, but if it's the
only one or even the main one, you're wasting your time.
regards, tom lane
