Tom Lane wrote:
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 wanted to post an updated patch even though there are still things not working again after conversion to bare expressions. Note that I hacked enough of the executor stuff so I could test my changes on the parser area. The basic "INSERT ... VALUES (...), (...), ..." does work, but without DEFAULT again :-(.
The good news is that from a memory and perfomance standpoint, my simple test now shows us outperforming mysql:
$loopcount = 1000000; Postgres: multi-INSERT-at-once Elapsed time is 12 seconds ~420MB MySQL: multi-INSERT-at-once Elapsed time is 17 seconds ~600MB $loopcount = 2000000; Postgres: multi-INSERT-at-once Elapsed time is 29 seconds ~730MB MySQL: multi-INSERT-at-once Elapsed time is 37 seconds ~1.2GB (this one is from memory -- I didn't write it in my notes) Joe
multi-insert-r18.diff.gz
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
