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

From Julien Rouhaud
Subject Re: Online checksums verification in the backend
Date
Msg-id CAOBaU_a-=xi6mPF5imNKMFRAoBEpkYkkAoW9Ss+XA4qApZ6WqQ@mail.gmail.com
Whole thread Raw
In response to Re: Online checksums verification in the backend  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Online checksums verification in the backend  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Fri, Sep 11, 2020 at 9:34 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.

Thanks!

> > 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?

I used all default settings, but by default checksum_cost_delay is 0
so there shouldn't be any throttling.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Online checksums verification in the backend
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: New statistics for tuning WAL buffer size