Re: Speed up Clog Access by increasing CLOG buffers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Speed up Clog Access by increasing CLOG buffers
Date
Msg-id CA+TgmobTdYgh24XNHMoGansYn=zCH5WzAg58jAeNA8WEVUbrbA@mail.gmail.com
Whole thread Raw
In response to Re: Speed up Clog Access by increasing CLOG buffers  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Speed up Clog Access by increasing CLOG buffers
List pgsql-hackers
On Sun, Feb 21, 2016 at 7:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
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-run
variation or an actual regression, I will re-run these tests on single
client 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 I
posted in this thread to increase clog buffers can make significant
reduction in contention on CLogControlLock.  OTOH, I think introducing
regression at single-client is also not a sane thing to do, so lets
first try to find if there is actually any regression and if it is, can
we mitigate it by writing code with somewhat fewer instructions or
in a slightly different way and then we can decide whether it is good
to reject the patch or not.  Does that sound reasonable to you?

Yes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [JDBC] JDBC behaviour
Next
From: Craig Ringer
Date:
Subject: Re: Writing new unit tests with PostgresNode