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