On 2014-11-19 19:12:22 +0200, Heikki Linnakangas wrote:
> On 11/19/2014 06:49 PM, Robert Haas wrote:
> >On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
> ><hlinnakangas@vmware.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.
Right. Although it hugely depends on the checkpoint settings - if
there's many FPWs it doesn't matter much.
Obviously it won't be a fourfold performance improvement in the server,
but given the profiles I've seen in the past I'm pretty sure it'll bee a
benefit.
> That said, the speedup is so large that I'm sure this is a big win in the
> server too, despite those factors.
Yep. I've done some fast and loose benchmarking in the past and it was
quite noticeable. Made XLogInsert() nearly entirely drop from profiles.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
