On Thu, Nov 28, 2013 at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I did think about instituting a rule that all valid entries must be
> consecutive at the front, but it's far from clear that the extra logic
> needed to maintain that invariant would cost less than what's saved.
FWIW, I considered that approach when initially developing the feature
and came to the same conclusion. Now we could benchmark it...
> One other thing we could do if we wanted to micro-optimize here would
> be to fetch the fpLockBits value into a local register; the existing
> coding most likely reads it out of the PGPROC again on every iteration.
> You could further imagine coding the search loops like
>
> for (f = 0, bits = proc->fpLockBits; bits != 0; f++, bits >>= 3)
> {
> if (bits & 7 != 0) do something with this slot;
> }
>
> so that you'd fall out of the loop as soon as there were no later
> occupied slots.
…and we could also benchmark this. But I bet there are more fruitful
optimization targets elsewhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
