Tom Lane wrote:
So what I'm currently thinking is
1. Implement ValuesScan.
2. Convert all existing uses of Result without a child node into
ValuesScan.
3. Rename Result to Filter and rip out whatever code is only used for
the no-child-node case.
Steps 2 and 3 are just in the nature of housekeeping and can wait till
after the VALUES feature is in.
Sounds good to me.
As far as avoiding overhead goes, here's what I'm thinking:
* The Values RTE node should contain a list of lists of bare
expressions, without TargetEntry decoration (you probably do not
need ResTarget in the raw parse tree for VALUES, either).
* The ValuesScan plan node will just reference this list-of-lists
(avoiding making a copy). It will need to contain a targetlist
because all plan nodes do, but the base version of that will just
be a trivial "Var 1", "Var 2", etc. (The planner might replace that
with a nontrivial targetlist in cases such as the example above.)
I'll work on that today.
* At runtime, ValuesScan evaluates each sublist of expressions and
stores the results into a virtual tuple slot which is returned as
the "scan tuple" to execScan. If the targetlist is nontrivial then
it is evaluated with this tuple as input. If the targetlist is
a trivial Var list then the existing "physical tuple" optimization
kicks in and execScan will just return the scan tuple unmodified.
So for INSERT ... VALUES, the execScan layer will cost us nothing
in memory space and not much in execution time.
There are still some things I don't like about the way you did
ValuesScan but I'll work on improving that.
OK.
Thanks,
Joe
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
