Re: What exactly is our CRC algorithm?
От | Abhijit Menon-Sen |
---|---|
Тема | Re: What exactly is our CRC algorithm? |
Дата | |
Msg-id | 20141121101145.GA8372@toroid.org обсуждение исходный текст |
Ответ на | Re: What exactly is our CRC algorithm? (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Ответы |
Re: What exactly is our CRC algorithm?
Re: What exactly is our CRC algorithm? Re: What exactly is our CRC algorithm? |
Список | pgsql-hackers |
At 2014-11-20 13:47:00 +0530, ams@2ndQuadrant.com wrote: > > > Suggestions for how to address (b) are welcome. With help from Andres, I set up a workload where XLogInsert* was at the top of my profiles: server with fsync and synchronous_commit off, and pgbench running a multiple-row insert into a single-text-column table with -M prepared -c 25 -t 250000 -f script. Unfortunately I can't see much difference despite running things with slightly different parameters a few dozen times. For example, here are real/user/sys times from three runs each with HEAD and slice-by-8 on an otherwise-idle i7-3770 server with a couple of undistinguished Toshiba 7200rpm SATA disks in RAID-1: HEAD: 2m24.822s/0m18.776s/0m23.156s 3m34.586s/0m18.784s/0m24.324s 3m41.557s/0m18.640s/0m23.920s Slice-by-8: 2m26.977s/0m18.420s/0m22.884s 3m36.664s/0m18.376s/0m24.232s 3m43.930s/0m18.580s/0m24.560s I don't know how to interpret these results (especially the tendency for the tests to slow down as time passes, with every version). At best, it shows that the new CRC code doesn't hurt, at worst it's just irrelevant. Supporting the latter interpretation, using the hardware-CRC patch also gives similar results (but XLogInsert is not at the top of the profile). Hardware-CRC: 2m29.090s/0m18.652s/0m23.764s 3m30.188s/0m18.692s/0m25.332s 3m38.110s/0m20.424s/0m24.532s If anyone has other suggestions, I'm all ears. -- Abhijit
В списке pgsql-hackers по дате отправления: