Re: Online checksums verification in the backend
От | Julien Rouhaud |
---|---|
Тема | Re: Online checksums verification in the backend |
Дата | |
Msg-id | CAOBaU_a-=xi6mPF5imNKMFRAoBEpkYkkAoW9Ss+XA4qApZ6WqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Online checksums verification in the backend (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Online checksums verification in the backend
|
Список | 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 по дате отправления: