Re: lock contention on parallel COPY ? - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: lock contention on parallel COPY ?
Date
Msg-id 48DD1697.4090505@kaltenbrunner.cc
Whole thread Raw
In response to Re: lock contention on parallel COPY ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: lock contention on parallel COPY ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> heh no log archiving - I actually said that I'm now playing with 
>> --truncate-before-load which seems to cause a noticeable performance (as 
>> in IO generated) increase but I still see >130000 context switches/s and 
>> a profile that looks like:
> 
>> 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
> 
> Still a lot of contention for something, then.  You might try turning on
> LWLOCK_STATS (this only requires recompiling storage/lmgr/lwlock.c) to
> get some evidence about what.

that one generates a huge amount of logs - output for ~60s into the load 
is available here:

http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)


Stefan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: lock contention on parallel COPY ?
Next
From: "Brendan Jurd"
Date:
Subject: Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)