Re: What exactly is our CRC algorithm?

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: What exactly is our CRC algorithm?
Date: 2014-11-19 17:12:22
Message-ID: 546CCF76.7010001@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/19/2014 06:49 PM, Robert Haas wrote:
> On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> That's an interesting choice of workload. That sure is heavy on the CRC
>> calculation, but the speed of pg_xlogdump hardly matters in real life.
>
> But isn't a workload that is heavy on CRC calculation exactly what we
> want here? That way we can see clearly how much benefit we're getting
> on that particular part of the computation. It'll still speed up
> other workloads, too, just not as much.

Sure. But pg_xlogdump's way of using the CRC isn't necessarily
representative of how the backend uses it. It's probably pretty close to
WAL replay in the server, but even there the server might be hurt more
by the extra cache used by the lookup tables. And a backend generating
the WAL computes the CRC on smaller pieces than pg_xlogdump and WAL redo
does.

That said, the speedup is so large that I'm sure this is a big win in
the server too, despite those factors.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-19 17:16:24 Re: Move Deprecated configure.in to configure.ac
Previous Message Heikki Linnakangas 2014-11-19 17:04:11 Re: Increasing test coverage of WAL redo functions