Skip site navigation (1) Skip section navigation (2)

Re: 8.4 open item: copy performance regression?

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-06-19 15:05:44
Subject: Re: 8.4 open item: copy performance regression?
Previous:From: Marko KreenDate: 2009-06-19 13:59:02
Subject: Re: 8.4 open item: copy performance regression?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group