Обсуждение: Hash twice

Поиск
Список
Период
Сортировка

Hash twice

От
Simon Riggs
Дата:
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

Вложения

Re: Hash twice

От
Robert Haas
Дата:
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



Re: Hash twice

От
Simon Riggs
Дата:
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