| From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 8.4 open item: copy performance regression? |
| Date: | 2009-06-19 14:52:39 |
| Message-ID: | 4A3BA637.8060600@kaltenbrunner.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>
> Kevin Grittner wrote:
>>
>> 8.3.7
>> real 0m24.249s
>> real 0m24.054s
>> real 0m24.361s
>>
>> 8.4rc1
>> real 0m33.503s
>> real 0m34.198s
>> real 0m33.931s
>>
>>
>>
>
> Ugh. This looks like a poster child case for a benchfarm ...
indeed...
>
> Is there any chance you guys could triangulate this a bit? Good initial
> triangulation points might be the end of each commitfest. (I have a
> vested interest in making sure COPY performance doesn't regress, since
> it will affect parallel restore's speed in spades.)
Maybe parallel restore is the issue why we haven't noticed this earlier.
The case that regressed this way is WAL logged COPY, COPY that can
bypass WAL (which typically happens in parallel restore now) is actually
a bit faster in my testing in 8.4.
I will try and see if I can figure out what caused the regression...
Stefan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-06-19 15:05:44 | Re: 8.4 open item: copy performance regression? |
| Previous Message | Marko Kreen | 2009-06-19 13:59:02 | Re: 8.4 open item: copy performance regression? |