Re: 8.4 open item: copy performance regression?
От | Kevin Grittner |
---|---|
Тема | Re: 8.4 open item: copy performance regression? |
Дата | |
Msg-id | 4A3A69380200002500027DBF@gw.wicourts.gov обсуждение исходный текст |
Ответ на | 8.4 open item: copy performance regression? (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: 8.4 open item: copy performance regression?
|
Список | pgsql-hackers |
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > A 25-30% performance regression in our main bulk loading mechanism > should at least be explained before the release... I think a performance regression of that magnitude merits holding up a release to resolve. Note that in a follow-up post showing the slow 8.4 copying on Linux, the copy was 11.7% to 19.3% *faster* on 8.4 when the WAL writing was suppressed: http://archives.postgresql.org/pgsql-performance/2009-06/msg00219.php Extracting from that post: # I can reproduce that on Linux(CentoS 5.3/x86_64, Nehalem Xeon E5530) # on 8.4 I get: # # 3m59/4m01/3m56s runtime and a profile of # # samples % symbol name # 636302 19.6577 XLogInsert # 415510 12.8366 CopyReadLine # on 8.3.7 I get 2m58s,2m54s,2m55s # # and a profile of: # # samples % symbol name # 460966 16.2924 XLogInsert # 307386 10.8643 CopyReadLine # If I do the same test utilizing WAL bypass the picture changes: # # 8.3 runtimes:2m16,2min14s,2min22s # 8.4 runtime: 2m1s,2m,1m59s Is there a reason to believe that the XLogInsert part of this *only* affects bulk loads? -Kevin
В списке pgsql-hackers по дате отправления: