From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: concurrent COPY performance |
Date: | 2009-06-16 21:49:41 |
Message-ID: | 4A381375.2070906@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure wrote:
> On Tue, Jun 16, 2009 at 12:47 PM, Stefan
> Kaltenbrunner<stefan(at)kaltenbrunner(dot)cc> wrote:
>
>> Hi!
>>
>> I have been doing some bulk loading testing recently - mostly with a focus
>> on answering why we are "only" getting a (max of) cores/2(up to around 8
>> cores even less with more) speedup using parallel restore.
>> What I found is that on some fast IO-subsystem we are CPU bottlenecked on
>> concurrent copy which is able to utilize WAL bypass (and scale up to around
>> cores/2) and performance without wal bypass is very bad.
>> In the WAL logged case we are only able to get a 50% speedup using the
>> second process already and we are never able to scale better than 3x (up to
>> 8 cores) and performance degrades even after that point.
>>
>
> how are you bypassing wal? do I read this properly that on your 8
> core system you are getting 4x speedup with wal bypass and 3x speedup
> without?
>
If a table is created or truncated in the same transaction that does the
load, and archiving is not on, the COPY is not WALed. That is why
parallel restore wraps the COPY in a transaction and precedes it with a
TRUNCATE if it created the table.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-06-16 22:14:33 | Re: concurrent COPY performance |
Previous Message | Merlin Moncure | 2009-06-16 21:33:12 | Re: concurrent COPY performance |