From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: explain and PARAM_EXEC |
Date: | 2010-02-20 11:57:44 |
Message-ID: | m23a0w5dc7.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> It's really not much different from a function call with subplans as
> functions. The PARAM_EXEC stuff looks just like 1950's era
> non-reentrant function parameter passing mechanisms, back before anybody
> had thought of recursive functions and they passed a function's
> parameters in fixed storage locations. It's okay for this because
> subplan trees are never recursive ...
<hand waving alert>
How much does this stuff is dependent on the current state of the
backend? If not that much, maybe the planner could consider costs of
having another backend started to handle the subplan. We'd need a
tuplestore or some other place to exchange results (a unix style pipe
maybe, but we do support windows as a platform), and a special executor
mode for running a subplan, maybe more than once. Oh, and a way to share
the same snapshot in more than one backend too, but that's being worked
on I think.
Ok that's a far stretch from the question at hand, but would that be a
plausible approach to have parallel queries in PostgreSQL ?
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-02-20 12:53:04 | Re: explain and PARAM_EXEC |
Previous Message | Shane Ambler | 2010-02-20 10:28:09 | Re: alpha4 bundled -- please verify |