Re: SQL/MED - file_fdw - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: SQL/MED - file_fdw
Date
Msg-id 4D5874D9.2090901@dunslane.net
Whole thread Raw
In response to Re: SQL/MED - file_fdw  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers

On 02/12/2011 05:33 PM, Noah Misch wrote:
> On Sat, Feb 12, 2011 at 03:42:17PM -0600, Kevin Grittner wrote:
>> In two hours of testing with a 90GB production database, the copy
>> patch on top of HEAD ran 0.6% faster than HEAD for pg_dumpall
>> (generating identical output files), but feeding that in to and
>> empty cluster with psql ran 8.4% faster with the patch than without!
>> I'm going to repeat that latter with more attention to whether
>> everything made it in OK.  (That's not as trivial to check as the
>> dump phase.)
>>
>> Do you see any reason that COPY FROM should be significantly
>> *faster* with the patch?
> No.  Up to, say, 0.5% wouldn't be too surprising, but 8.4% is surprising.  What
> is the uncertainty of that figure?
>
>

We have seen in the past that changes that might be expected to slow 
things down slightly can have the opposite effect. For example, see 
<http://people.planetpostgresql.org/andrew/index.php?/archives/37-Puzzling-results.html> 
where Tom commented:
   Yeah, IME it's not unusual for microbenchmark results to move a   percent or three in response to any code change at
all,even   unrelated ones. I suppose it's from effects like critical loops   breaking across cache lines differently
thanbefore.
 

cheers

andrew


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [Mingw-users] mingw64
Next
From: Tom Lane
Date:
Subject: Re: Scheduled maintenance affecting gitmaster