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

Attachment: multi-insert-r18.diff.gz
Description: GNU Zip compressed data

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to