From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, David Roussel <pgsql-performance(at)diroussel(dot)xsmail(dot)com>, Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net>, pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: COPY vs INSERT |
Date: | 2005-05-06 13:51:55 |
Message-ID: | 13782.1115387515@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> wrote:
>> Has thought been given to supporting inserting multiple rows in a single
>> insert?
> It's on the TODO list. I don't remember anyone bringing this up for about
> a year now, so I doubt anyone is actively working on it.
It is on TODO but I think it is only there for standards compliance.
It won't produce near as much of a speedup as using COPY does ---
in particular, trying to put thousands of rows through at once with
such a command would probably be a horrible idea. You'd still have
to pay the price of lexing/parsing, and there would also be considerable
flailing about with deducing the data type of the VALUES() construct.
(Per spec that can be used in SELECT FROM, not only in INSERT, and so
it's not clear to what extent we can use knowledge of the insert target
columns to avoid running the generic union-type-resolution algorithm for
each column of the VALUES() :-(.) Add on the price of shoving an
enormous expression tree through the planner and executor, and it starts
to sound pretty grim.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-06 13:59:43 | Re: Bad choice of query plan from PG 7.3.6 to PG 7.3.9 |
Previous Message | Bruno Wolff III | 2005-05-06 12:38:31 | Re: COPY vs INSERT |