On Fri, May 06, 2005 at 09:30:46AM +0200, Dennis Bjorklund wrote:
> The sql standard include this, except that you can not have the outer ().
> So it should be
>
> INSERT INTO table VALUES
> (1,2,3),
> (4,5,6),
> (7,8,9);
>
> Do DB2 demand these extra ()?
My recollection is that it d
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> 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 w
On Fri, May 06, 2005 at 01:51:29 -0500,
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Wed, May 04, 2005 at 10:22:56PM -0400, Tom Lane wrote:
> > Also, there is a whole lot of one-time-per-statement overhead that can
> > be amortized across many rows instead of only one. Stuff like opening
> > t
In article <[EMAIL PROTECTED]>,
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Fri, 6 May 2005, Jim C. Nasby wrote:
>> Has thought been given to supporting inserting multiple rows in a single
>> insert? DB2 supported:
>>
>> INSERT INTO table VALUES(
>> (1,2,3),
>> (4,5,6),
>> (7,8,9)
>> );
>>
On Fri, 6 May 2005, Jim C. Nasby wrote:
> Has thought been given to supporting inserting multiple rows in a single
> insert? DB2 supported:
>
> INSERT INTO table VALUES(
> (1,2,3),
> (4,5,6),
> (7,8,9)
> );
>
> I'm not sure how standard that is or if other databases support it.
The
On Wed, May 04, 2005 at 10:22:56PM -0400, Tom Lane wrote:
> Also, there is a whole lot of one-time-per-statement overhead that can
> be amortized across many rows instead of only one. Stuff like opening
> the target table, looking up the per-column I/O conversion functions,
> identifying trigger f
Christopher Petrilli wrote:
On 5/4/05, Mischa Sandberg <[EMAIL PROTECTED]> wrote:
Quoting David Roussel <[EMAIL PROTECTED]>:
COPY invokes all the same logic as INSERT on the server side
(rowexclusive locking, transaction log, updating indexes, rules).
The difference is that all the rows are insert
On Wed, 4 May 2005, Mischa Sandberg wrote:
> Quoting Kris Jurka <[EMAIL PROTECTED]>:
>
> > Not true. A client may send any number of Bind/Execute messages on
> > a prepared statement before a Sync message.
> Hunh. Interesting optimization in the JDBC driver. I gather it is
> sending a str
Quoting Kris Jurka <[EMAIL PROTECTED]>:
> On Wed, 4 May 2005, Mischa Sandberg wrote:
>
> > Copy makes better use of the TCP connection for transmission. COPY
> uses
> > the TCP connection like a one-way pipe. INSERT is like an RPC: the
> > sender has to wait until the insert's return statu
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> So what's the difference between a COPY and a batch of INSERT
>> statements. Also, surely, fsyncs only occur at the end of a
>> transaction, no need to fsync before a commit has been issued, right?
> With COPY, the data being inserted itself
So what's the difference between a COPY and a batch of INSERT
statements. Also, surely, fsyncs only occur at the end of a
transaction, no need to fsync before a commit has been issued, right?
With COPY, the data being inserted itself does not have to pass through
the postgresql parser.
Chris
---
On Wed, 4 May 2005, Mischa Sandberg wrote:
> Copy makes better use of the TCP connection for transmission. COPY uses
> the TCP connection like a one-way pipe. INSERT is like an RPC: the
> sender has to wait until the insert's return status roundtrips.
Not true. A client may send any number of
On 5/4/05, Mischa Sandberg <[EMAIL PROTECTED]> wrote:
> Quoting David Roussel <[EMAIL PROTECTED]>:
>
> > > COPY invokes all the same logic as INSERT on the server side
> > > (rowexclusive locking, transaction log, updating indexes, rules).
> > > The difference is that all the rows are inserted as
David Roussel wrote:
COPY invokes all the same logic as INSERT on the server side
(rowexclusive locking, transaction log, updating indexes, rules).
The difference is that all the rows are inserted as a single
transaction. This reduces the number of fsync's on the xlog,
which may be a limiting facto
Quoting David Roussel <[EMAIL PROTECTED]>:
> > COPY invokes all the same logic as INSERT on the server side
> > (rowexclusive locking, transaction log, updating indexes, rules).
> > The difference is that all the rows are inserted as a single
> > transaction. This reduces the number of fsync's on
> COPY invokes all the same logic as INSERT on the server side
> (rowexclusive locking, transaction log, updating indexes, rules).
> The difference is that all the rows are inserted as a single
> transaction. This reduces the number of fsync's on the xlog,
> which may be a limiting factor for you.
> Steven Rosenstein <[EMAIL PROTECTED]> writes:
> > My question is, are there any advantages, drawbacks, or outright
> > restrictions to using multiple simultaneous COPY commands to load
> data into
> > the same table?
Do you mean, multiple COPY commands (connections) being putline'd from
the same
17 matches
Mail list logo
