Re: explain and PARAM_EXEC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: explain and PARAM_EXEC
Date: 2010-02-20 15:11:32
Message-ID: 356.1266678692@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-20 15:14:24 Re: explain and PARAM_EXEC
Previous Message Dimitri Fontaine 2010-02-20 13:31:01 parallelizing subplan execution (was: explain and PARAM_EXEC)