On Tue, Jan 3, 2012 at 10:21 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> I'm happy with how this looks, except (as noted in a code comment)
> that there seems to be room for optimization of the calculation
> itself. Details below:
...
> (3) Rather than having PageSetVerificationInfo() use memcpy,
> followed by pass through the copied data to calculate the checksum,
> might it be better to have a "copy and calculate" version of the
> function (as in VMware's original patch) to save an extra pass over
> the page image?
> Other than these performance tweaks around the calculation phase, I
> didn't spot any problems. I beat up on it a bit on a couple
> machines without hitting any bugs or seeing any regression test
> failures.
My focus was on getting something working first, then tuning. If we're
agreed that we have everything apart from the tuning then we can
proceed with tests to see which works better.
The copy and calculate approach might get in the way of hardware
prefetch since in my understanding the memory fetch time exceeds the
calculation time. As discussed elsewhere using that code or not would
not stop that work being credited.
David, please can you rework the VMware calc patch to produce an
additional 16-bit checksum mechanism in a way compatible with the
16bit patch, so we can test the two versions of the calculation? We
can make the GUC an enum so that the page checksum is selectable (for
testing).
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
