Re: Online checksums verification in the backend - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Online checksums verification in the backend
Date
Msg-id 20200911073412.GJ2743@paquier.xyz
Whole thread Raw
In response to Re: Online checksums verification in the backend  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Online checksums verification in the backend  (Julien Rouhaud <rjuju123@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: bttanakahbk
Date:
Subject: Re: track_planning causing performance regression
Next
From: Julien Rouhaud
Date:
Subject: Re: Online checksums verification in the backend