From: | Shaun Thomas <bonesmoses(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Having some problems with concurrent COPY commands |
Date: | 2015-10-13 14:14:01 |
Message-ID: | CAB78C+D1N3d-WWu3OCY6Ugf=+jKrsxfL=wky5D3crQ-BDy6hDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Oct 13, 2015 at 2:32 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> 80% of the CPU time is spent in the b-tree comparison function.
In the logs, my duration per COPY command increases from about 1400ms
for one process to about 3800ms when I have four running concurrently.
That's really my only data point, unfortunately. Strace isn't super
helpful because it just says 70-ish% of the time is wait4, but that's
not significantly different than the results using one process.
Everything else is bog standard default. I bumped up
checkpoint_segments to avoid checkpoints during the test, and
increased work_mem and maintenance_work_mem to avoid disk affecting
results, and still got the same behavior.
I wasn't blaming the patch. :) I thought it didn't get merged or
something, and after learning that wasn't the case, my only theory
went out the window. I'm a bit stuck, because this seems incredibly
wrong. I'll keep digging.
--
Shaun Thomas
bonesmoses(at)gmail(dot)com
http://bonesmoses.org/
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-10-13 14:23:36 | Re: Having some problems with concurrent COPY commands |
Previous Message | Heikki Linnakangas | 2015-10-13 09:32:38 | Re: Having some problems with concurrent COPY commands |