Thread

1. Hash twice

   Simon Riggs <simon@2ndquadrant.com> — 2013-01-12T16:39:15Z

   Lock code says it calculates "hash value once and then pass around as needed".
   
   But it actually calculates it twice for new locks.
   
   Trivial patch attached to make it follow the comments in
   LockTagHashCode and save a few cycles.
   
   -- 
    Simon Riggs                   http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services
   

2. Re: Hash twice

   Robert Haas <robertmhaas@gmail.com> — 2013-01-14T19:12:24Z

   On Sat, Jan 12, 2013 at 11:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
   > Lock code says it calculates "hash value once and then pass around as needed".
   >
   > But it actually calculates it twice for new locks.
   >
   > Trivial patch attached to make it follow the comments in
   > LockTagHashCode and save a few cycles.
   
   Hmm.  This is a nice idea, but it doesn't look right to me, because
   you're searching LockMethodLocalHash with a hash code intended to be
   used in LockMethodLockHash, and the two hashing schemes are not
   compatible, because the former is hashing a LOCALLOCKTAG, and the
   latter is hashing a LOCKTAG, and both are just using tag_hash.
   
   On the flip side if I'm wrong and the hashing schemes are compatible,
   there are other places in the file where the same trick could be
   employed.
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise PostgreSQL Company
   
   
   

3. Re: Hash twice

   Simon Riggs <simon@2ndquadrant.com> — 2013-01-14T19:50:43Z

   On 14 January 2013 19:12, Robert Haas <robertmhaas@gmail.com> wrote:
   > On Sat, Jan 12, 2013 at 11:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
   >> Lock code says it calculates "hash value once and then pass around as needed".
   >>
   >> But it actually calculates it twice for new locks.
   >>
   >> Trivial patch attached to make it follow the comments in
   >> LockTagHashCode and save a few cycles.
   >
   > Hmm.  This is a nice idea, but it doesn't look right to me, because
   > you're searching LockMethodLocalHash with a hash code intended to be
   > used in LockMethodLockHash, and the two hashing schemes are not
   > compatible, because the former is hashing a LOCALLOCKTAG, and the
   > latter is hashing a LOCKTAG, and both are just using tag_hash.
   
   You're right. At local level we need to refcount requests, whereas we
   only ever pass first request through to main table. That means the
   unique key is different.
   
   > On the flip side if I'm wrong and the hashing schemes are compatible,
   > there are other places in the file where the same trick could be
   > employed.
   
   But having said that, we already make ProcLockHash use a variation of
   the LockHash to avoid recalculation.
   
   So we should just make
        LocalLockTagHashCode = LockTagHashCode() + mode;
   
   Then we can use LockTagHashCode everywhere, which is easier to do than
   documenting why we don't.
   
   
   Anyway, just an idle thought while looking into something else.
   
   -- 
    Simon Riggs                   http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services