Skip site navigation (1) Skip section navigation (2)

Re: Hash twice

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash twice
Date: 2013-01-14 19:50:43
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 14 January 2013 19:12, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jan 12, 2013 at 11:39 AM, Simon Riggs <simon(at)2ndquadrant(dot)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         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: David JohnstonDate: 2013-01-14 20:09:59
Subject: Re: count(*) of zero rows returns 1
Previous:From: Robert HaasDate: 2013-01-14 19:12:24
Subject: Re: Hash twice

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group