Re: ResourceOwner refactoring - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: ResourceOwner refactoring
Date
Msg-id CAOBaU_a1Rt_Vn0XxWU1fiGrWWzEZMrCEjxDDsEePGc=i9EYVmQ@mail.gmail.com
Whole thread Raw
In response to Re: ResourceOwner refactoring  (Michael Paquier <michael@paquier.xyz>)
Responses Re: ResourceOwner refactoring  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Thu, Nov 19, 2020 at 10:16 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Nov 18, 2020 at 10:50:08AM +0200, Heikki Linnakangas wrote:
> > If RESOWNER_ARRAY_STATS is increased to 16, all the lookups fit in the
> > array. But I haven't done any benchmarking to see which is faster.
>
> My gut tells me that your guess is right, but it would be better to be
> sure.
>
> > BTW, I think there would be an easy win in the hashing codepath, by changing
> > to a cheaper hash function. Currently, with or without this patch, we use
> > hash_any(). Changing that to murmurhash32() or something similar would be a
> > drop-in replacement.
>
> Good idea.

+1, and +1 for this refactoring.

I just saw a minor issue in a comment while reviewing the patch:

[...]
+ /* Is there space in the hash? If not, enlarge it. */

  /* Double the capacity of the array (capacity must stay a power of 2!) */
- newcap = (oldcap > 0) ? oldcap * 2 : RESARRAY_INIT_SIZE;
[...]

The existing comment is kept as-is, but it should mention that it's
now the hash capacity that is increased.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Move OpenSSL random under USE_OPENSSL_RANDOM
Next
From: japin
Date:
Subject: Re: Terminate the idle sessions