Re: Online checksums verification in the backend

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: Online checksums verification in the backend
Date: 2020-09-11 07:34:12
Message-ID: 20200911073412.GJ2743@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-09-11 07:49:16 Re: Online checksums verification in the backend
Previous Message bttanakahbk 2020-09-11 07:23:28 Re: track_planning causing performance regression