At 2014-11-19 19:12:22 +0200, hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers