From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, hanada(at)metrosystems(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - file_fdw |
Date: | 2011-02-14 00:18:33 |
Message-ID: | 4D5874D9.2090901@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 than before.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-14 00:27:41 | Re: Scheduled maintenance affecting gitmaster |
Previous Message | Andrew Dunstan | 2011-02-14 00:06:27 | Re: [Mingw-users] mingw64 |