Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.3/8.9.3) with ESMTP id TAA34867
	for <pgsql-interfaces@postgreSQL.org>;
	Wed, 23 Jun 1999 19:31:26 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA22129;
	Wed, 23 Jun 1999 19:30:24 -0400 (EDT)
To: Steven Bradley <sbradley@llnl.gov>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Performance 
In-reply-to: Your message of Wed, 23 Jun 1999 15:05:09 -0700
	<3.0.5.32.19990623150509.0092e990@poptop.llnl.gov>
Date: Wed, 23 Jun 1999 19:30:24 -0400
Message-ID: <22127.930180624@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Steven Bradley <sbradley@llnl.gov> writes:
> I wanted to use a prepared SQL statement, but it turns out that Postgres
> runs the query through the parser-planner-executor cycle on each iteration.
>  There is no way to prevent this.

> The next thing I though of doing was to "bulk load" several records in one
> INSERT through the use of array processing.  Do any of the Postgres
> interfaces support this?  (by arrays, I don't mean array columns in the
> table).

If you're just inserting literal data, use COPY FROM STDIN instead of
INSERTs.  Much less per-tuple overhead, although it's uglier.

			regards, tom lane