From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: lock contention on parallel COPY ? |
Date: | 2008-09-26 19:24:25 |
Message-ID: | 1222457065.4445.1007.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2008-09-26 at 20:07 +0200, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> >> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> >>> samples % symbol name
> >>> 55526 16.5614 LWLockAcquire
> >>> 29721 8.8647 DoCopy
> >>> 26581 7.9281 CopyReadLine
> >>> 25105 7.4879 LWLockRelease
> >>> 15743 4.6956 PinBuffer
> >>> 14725 4.3919 heap_formtuple
> >
> >> Probably loading a table with a generated PK or loading data in
> >> ascending sequence, so its contending heavily for the rightmost edge of
> >> the index.
> >
> > No, given that DoCopy and CopyReadLine are right up there, I think we're
> > still looking at the COPY phase, not index building.
> >
> > The profile will probably change completely once index building
> > starts...
>
> yeah this profile is only showing the COPY phase ...
Try using this Postgres core patch. It's a updated version of my
fast_copy.v4.patch from Patches: Bulk Insert tuning 20 Mar 2008
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Attachment | Content-Type | Size |
---|---|---|
fast_copy.v4a.patch | text/x-patch | 16.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-09-26 19:39:08 | Re: About the parameter of API: PQprepared |
Previous Message | Merlin Moncure | 2008-09-26 18:42:16 | Re: About the parameter of API: PQprepared |