From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Date: | 2003-08-12 20:37:33 |
Message-ID: | 16303.1060720653@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Rod Taylor <rbt(at)rbt(dot)ca> writes:
>> Do you happen to have any numbers comparing prepared inserts in a single
>> transaction against copy?
> COPY is about a factor of 6 faster, it appears. I got 11.8 versus
> 1.87 seconds for loading the same amount of data (with the 3-column
> test table). So COPY's not gonna go away any time soon.
BTW, that was on a local Unix-socket connection. On a network
connection, COPY would have a huge advantage because (a) it could
transfer multiple rows per packet, if your rows are not too long,
and (b) you would not have to wait for the server to answer back
before sending the next packet.
In theory you could pipeline INSERT commands like that too, but not
with libpq.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-12 20:41:30 | Re: Parsing speed (was Re: pgstats_initstats() cost) |
Previous Message | Joe Conway | 2003-08-12 20:35:40 | Re: Parsing speed (was Re: pgstats_initstats() cost) |