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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Online checksums verification in the backend
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: New statistics for tuning WAL buffer size