From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Marginal performance improvement for fast-path locking |
Date: | 2013-11-28 18:55:53 |
Message-ID: | CAOeZVieG3Qz1Or=HH7BLM7HgjBDdtg0JhMbvb+74TuLmjvjdxg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Nice idea, but would not be making an extra array just to hold the hot
entries be a better idea? I agree,the code added would be more
complex, but we could potentially drastically reduce the time for the
lookup, since only the smaller array will be mostly looked at.
Regards,
Atri
--
Regards,
Atri
l'apprenant
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-28 19:12:50 | Re: Marginal performance improvement for fast-path locking |
Previous Message | Tom Lane | 2013-11-28 18:46:23 | Marginal performance improvement for fast-path locking |