Re: What exactly is our CRC algorithm?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
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 13:13:30
Message-ID: 20141127131330.GA16294@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 27, 2014 at 11:19:51AM +0530, Abhijit Menon-Sen wrote:
> 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).

Thanks, these are good numbers.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-11-27 13:23:47 Re: Add CREATE support to event triggers
Previous Message Sameer Kumar 2014-11-27 12:39:12 Using pg_rewind for differential backup