From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Marginal performance improvement for fast-path locking |
Date: | 2013-11-28 18:46:23 |
Message-ID: | 15889.1385664383@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While debugging the recent fastpath lock unpleasantness, I noticed that
the code tends to use only the last few entries in the fpRelId[] arrays,
which seemed a bit surprising. The reason of course is the way that
FastPathGrantRelationLock() is written: it remembers the *last* unused
slot while scanning the array. This ends up wasting cycles in
FastPathUnGrantRelationLock(), as well as other places where we search
for an existing entry, since they'll generally have to iterate to the end
of the array to find it. We should prefer to put entries near the front
of the array, not the back. (Of course, if the array is about full then
it's going to be a wash, but in simple transactions we might only have a
few relations with fast-path locks.)
We could add an extra test in FastPathGrantRelationLock's loop to make
it remember the first unused slot rather than the last one, but that
would add some cycles there, partially negating any benefit. Instead
I propose that we reverse the direction of the search loop, as attached.
I doubt this will actually make any easily-measurable difference, so I've
not attempted to benchmark it, but in principle we should be able to save
a few loop iterations in places where we're holding locks. Comments?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
put-fastpath-array-entries-first.patch | text/x-diff | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-11-28 18:55:53 | Re: Marginal performance improvement for fast-path locking |
Previous Message | Andres Freund | 2013-11-28 17:35:07 | Re: Heads-Up: multixact freezing bug |