Re: What exactly is our CRC algorithm? - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: What exactly is our CRC algorithm?
Date
Msg-id 20141120042201.GA6345@toroid.org
Whole thread Raw
In response to Re: What exactly is our CRC algorithm?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: What exactly is our CRC algorithm?  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List pgsql-hackers
At 2014-11-19 19:12:22 +0200, hlinnakangas@vmware.com wrote:
>
> 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.

Sure. As Robert said, my initial benchmark was designed to show the CRC
improvements in isolation. I would be happy to conduct other tests and
post the numbers.

If I understand correctly, I need to demonstrate two things that are
"probably fine", but we don't have proof of:

(a) that the improvements in pg_xlogdump performance translate to an   improvement in the server when reading WAL.
(b) that the slice-by-8 code doesn't hurt performance for writing WAL.

To address (a), I am timing a standby restoring the same 11GB of WAL via
restore_command with and without the CRC patch. My earlier tests showed
that this time can vary quite a bit between runs even with no changes,
but I expect to see an improvement anyway.

Suggestions for how to address (b) are welcome.

-- Abhijit



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Bugfix and new feature for PGXS
Next
From: Amit Kapila
Date:
Subject: Re: group locking: incomplete patch, just for discussion