Re: What exactly is our CRC algorithm?

From: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: What exactly is our CRC algorithm?
Date: 2014-11-27 05:49:51
Message-ID: 20141127054951.GB22349@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2014-11-26 18:56:52 -0500, bruce(at)momjian(dot)us wrote:
>
> I would test it with fsync=off to remove the fsync delay. That will
> simulate an SSD or BBU controller.

The earlier tests were run with fsync=off.

I ran another round of the replay tests on the i7 server, this time
replaying 30GB of WAL segments.

master

16:08:03 16:16:23 08:20
16:19:33 16:28:03 08:30
16:32:20 16:41:17 08:57
16:42:42 16:51:22 08:40

8crc

16:52:11 16:59:48 07:37
17:01:07 17:08:30 07:23
17:22:16 17:30:11 07:55
17:31:29 17:39:06 07:37

These are just the results of the last four runs with each branch, but
the difference was consistent over many more runs.

To summarise: the slice-by-8 patch (a) increases pure CRC performance by
a large margin, (b) has a positive effect on reading WAL during replay,
(c) doesn't hurt XLogInsert in typical cases (which was the main worry).

-- Abhijit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-11-27 06:58:48 Re: OCLASS_ROWSECURITY oversights, and other kvetching
Previous Message Michael Paquier 2014-11-27 04:39:13 Re: Compiling C++ extensions on MSVC using scripts in src/tools