Re: What exactly is our CRC algorithm?
От | Abhijit Menon-Sen |
---|---|
Тема | Re: What exactly is our CRC algorithm? |
Дата | |
Msg-id | 20141120042201.GA6345@toroid.org обсуждение исходный текст |
Ответ на | Re: What exactly is our CRC algorithm? (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: What exactly is our CRC algorithm?
|
Список | 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 по дате отправления: