From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: bulk inserts |
Date: | 2009-09-29 23:16:48 |
Message-ID: | 20090929231648.GT5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Sep 29, 2009 at 12:17:51PM -0400, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
> > On Tue, Sep 29, 2009 at 08:45:55AM -0700, Alan Hodgson wrote:
> >> I think a big reason is also that the client can stream the data without
> >> waiting for a network round trip ack on every statement.
>
> > I don't think so. I'm pretty sure you can send multiple statements in a
> > single round trip.
>
> You can, but that doesn't scale to megabytes of data (at least not
> well).
No, but I didn't think that was being talked about. I was thinking
network round trip time does seem to become a thousand times less
important when you're putting a thousand statements together. This
would seem to imply that network latency can be almost arbitrarily
reduced.
> I think the big points are elimination of per-row network and
> transaction commit overhead ...
Well, if you start including transaction commit then you've just changed
semantics away from COPY. I was implicitly thinking of what changes
when you keep the same semantics as COPY.
> but there are some other optimizations
> in the COPY path too.
Cool, I'll continue to prefer COPY then!
--
Sam http://samason.me.uk/
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Friedman | 2009-09-29 23:22:51 | Postgresql Web Hosting |
Previous Message | Scott Marlowe | 2009-09-29 23:03:00 | Re: Performance evaluation of PostgreSQL's historic releases |