From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 16:27:36 |
Message-ID: | 48DD0D78.1040409@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Tom Lane wrote:
>>> I suppose Andrew didn't yet put in the hack to avoid WAL logging
>
>> Yes I did. That's what the --truncate-before-load switch does (or should
>> do).
>
> Well, it doesn't seem to be having any effect. Maybe Stefan is testing
> a configuration with xlog archiving enabled?
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
9748 2.9075 GetNewObjectId
8059 2.4037 pg_verify_mbstr_len
6825 2.0356 hash_search_with_hash_value
6386 1.9047 s_lock
5645 1.6837 heap_insert
5631 1.6795 PageAddItem
4723 1.4087 pg_atoi
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-26 16:38:14 | Re: lock contention on parallel COPY ? |
Previous Message | Tom Lane | 2008-09-26 16:15:57 | Re: lock contention on parallel COPY ? |