From: | NikhilS <nikkhils(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Gaetano Mendola" <mendola(at)bigfoot(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UPDATE using sub selects |
Date: | 2007-04-11 09:04:46 |
Message-ID: | d3c4af540704110204o3d67bad8l6a837d1dda111f1f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
> Hmm. That sounds like it would be a horrid mess. You need to decouple
> > the execution of the subplan from the use of its outputs, apparently.
> > There is some precedent for this in the way that InitPlans are handled:
> > the result of the subplan is stored into a ParamList array entry that's
> > later referenced by a Param node in the parent's expression tree. That
> > would generalize easily enough to setting more than one Param, but I'm
> > not clear on where you'd want to stick the subplan itself in the plan
> > tree, nor on what controls how often it needs to get evaluated.
>
>
>
>
Ended up using something similar to the above suggestion. I have posted the
patch to -patches based on this.
An important concern was where to stick the evaluation of the subqueries so
that they end up becoming subplans which are used in the execution. For this
I have added a new field in the "Query" structure. This entry gets
preprocessed similar to other fields of the Query from within
subquery_planner.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas ADI SD | 2007-04-11 11:45:28 | conflicting gettimeofday with MinGW |
Previous Message | Pavan Deolasee | 2007-04-11 08:13:43 | Re: [HACKERS] CIC and deadlocks |