Re: Speed up Clog Access by increasing CLOG buffers
От | Robert Haas |
---|---|
Тема | Re: Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | CA+TgmobTdYgh24XNHMoGansYn=zCH5WzAg58jAeNA8WEVUbrbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
|
Список | pgsql-hackers |
On Sun, Feb 21, 2016 at 7:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
Yes.
--
I mean, my basic feeling is that I would not accept a 2-3% regression in the single client case to get a 10% speedup in the case where we have 128 clients.I understand your point. I think to verify whether it is run-to-runvariation or an actual regression, I will re-run these tests on singleclient multiple times and post the result.
Perhaps you could also try it on a couple of different machines (e.g. MacBook Pro and a couple of different large servers).
A lot of people will not have 128 clients; quite a few will have a single session, or just a few. Sometimes just making the code more complex can hurt performance in subtle ways, e.g. by making it fit into the L1 instruction cache less well. If the numbers you have here are accurate, I'd vote to reject the patch.One point to note is that this patch along with first patch which Iposted in this thread to increase clog buffers can make significantreduction in contention on CLogControlLock. OTOH, I think introducingregression at single-client is also not a sane thing to do, so letsfirst try to find if there is actually any regression and if it is, canwe mitigate it by writing code with somewhat fewer instructions orin a slightly different way and then we can decide whether it is goodto reject the patch or not. Does that sound reasonable to you?
Yes.
В списке pgsql-hackers по дате отправления: