So, according to your advice, I've looked at the IndexScan implementation and here is what I came up with. At execution time, if I find an operation expression involving a Param, the param expression is evaluated with ExecEvalExpr (after being "initted" on the fly), and then considered exactly the same as a Const->constvalue.
Is there any problem with that I should know about ? I should maybe cache the resulting ExprState information during plan time, and only evaluate it during execution time. Would that make a huge difference ? Regarding the columns extraction information, I'll try to move my code in the plan-time hook. Thank you very much ! Best Regards, -- Ronan Dunklau 2011/10/20 Tom Lane <t...@sss.pgh.pa.us> > Ronan Dunklau <rdunk...@gmail.com> writes: > > Now, if I query my table like this (a subquery, joined on the outer > query), > > what info should I be able to parse from the PlanState ? > > > select name, (select max(value) from test t2 where t2.name = t1.name) as > max > > from test t1; > > > I don't really know much about postgresql internals, regarding execution > > plans, but here is what I guessed from what I managed to extract from the > > plan tree so far: > > > - The outer query is executed once, restricting only the needed columns > > - The subquery is executed once for each row, with: > > - all columns from the table are requested in a "target entry" node, > even > > if the query only need the name and value columns. > > - the value corresponding to the name from the outer query is somehow > > passed in as an Expr of type T_Param, in the quals field. > > > How can I retrieve the value from the Param struct ? > > You shouldn't be trying to do it at that level --- at most you ought to > do ExecEvalExpr on the expression tree. Otherwise you're going to end up > reinventing most of execQual.c to cover all cases. > > Right now we don't have very much infrastructure for helping FDWs push > restriction clauses over to the far end, which is what you seem to be > trying to do. I hope that will emerge in 9.2 or 9.3. If you want to > help you could start by looking at what the indexscan machinery does to > extract usable indexquals, because that's more or less the same problem. > If you feel that's out of your league, I'd suggest not bothering with > pushing clauses across right now. > > > The source does not help me much with what to do regarding the various > > fields in the struct. > > Does postgresql really fetch all columns in a subselect, or am I just > > parsing the tree in a wrong way ? > > Hmm, yeah, the planner thinks it's cheaper to extract all columns than > just some of them. This is appropriate for plain tables but I can see > that it's a bit dubious for a foreign table. Maybe we should shut off > the use_physical_tlist optimization for foreign tables. However, it's > not really intended that FDWs should be relying on the execution-time > targetlist to figure out which columns to pull across anyway. The > right way to make such an optimization is for the plan-time hook to > determine which columns are needed (look at the reltargetlist) and save > that information in the plan node. > > regards, tom lane >
