Ronan Dunklau <rdunklau@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
