Re: 8.4 open item: copy performance regression?

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