X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id DADC953422 for ; Fri, 6 May 2005 10:52:17 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 12147-07 for ; Fri, 6 May 2005 13:52:11 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id EAA275337C for ; Fri, 6 May 2005 10:52:09 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j46Dptqc013783; Fri, 6 May 2005 09:51:55 -0400 (EDT) To: Bruno Wolff III Cc: "Jim C. Nasby" , Christopher Kings-Lynne , David Roussel , Mischa Sandberg , pgsql-perform Subject: Re: COPY vs INSERT In-reply-to: <20050506123831.GA14417@wolff.to> References: <21154.1115136741@sss.pgh.pa.us> <1115146397.4277c89dc37b4@webmail.telus.net> <1115246490.1709.233393619@webmail.messagingengine.com> <42797C1A.3090303@familyhealth.com.au> <16747.1115259776@sss.pgh.pa.us> <20050506065129.GL88920@decibel.org> <20050506123831.GA14417@wolff.to> Comments: In-reply-to Bruno Wolff III message dated "Fri, 06 May 2005 07:38:31 -0500" Date: Fri, 06 May 2005 09:51:55 -0400 Message-ID: <13782.1115387515@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/61 X-Sequence-Number: 12225 Bruno Wolff III writes: > "Jim C. Nasby" 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