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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
