Re: Online checksums verification in the backend

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2020-09-11T07:34:12Z
Lists: pgsql-hackers
On Thu, Sep 10, 2020 at 08:06:10PM +0200, Julien Rouhaud wrote:
> The TPS is obviously overall extremely bad, but I can see that the submitted
> version added an overhead of ~3.9% (average of 5 runs), while the version
> without the optimisation added an overhead of ~6.57%.

Okay, so that stands as a difference.  I am planning to run some
benchmarks on my end as well, and see if I can see a clear
difference.

> This is supposed to be a relatively fair benchmark as all the data are cached
> on the OS side, so IO done while holding the bufmapping lock aren't too long,
> but we can see that we already get a non negligible benefit from this
> optimisation.  Should I do additional benchmarking, like dropping the OS cache
> and/or adding some write activity?  This would probably only make the
> unoptimized version perform even worse.

It would be also interesting to see the case where the pages are not
in the OS cache and see how bad it can get.  For the read-write case,
I am not sure as we may have some different overhead that hide the
noise.  Also, did you run your tests with the functions scanning at
full speed, with (ChecksumCostDelay < 0) so as there is no throttling?
--
Michael

Commits

  1. Revert pg_relation_check_pages()

  2. Fix incorrect placement of pfree() in pg_relation_check_pages()

  3. Add pg_relation_check_pages() to check on-disk pages of a relation

  4. Add CheckBuffer() to check on-disk pages without shared buffer loading

  5. Extend amcheck to check heap pages.