From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Combining hash values |
Date: | 2016-08-01 22:21:15 |
Message-ID: | CA+TgmoZuM+h5o7qYHdoqmWxmw54nVOdm21CqeGnKKMYbtoj6jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 1, 2016 at 7:24 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 1 August 2016 at 08:19, Greg Stark <stark(at)mit(dot)edu> wrote:
>> Surely combining multiple hashes is the same problem as hashing a block of
>> memory? Shouldn't we just use the same algorithm as hash_any()?
>
> Yes, I imagine that should work well. I suspect that Thomas's proposal
> would also probably work well, as would a number of other hashing
> algorithms with reasonable pedigree, such as the one used for array
> hashing. I don't have any particular preference, but I do know that
> what usually turns out to be disastrous is an arbitrary made-up
> formula like rotating and xor'ing. The last thing we should attempt to
> do is invent our own hashing algorithms.
+1. (x << 1) | y isn't the stupidest way of combining hash values
anybody's ever invented, but there are surely others that are better.
I don't much care whether we adopt Thomas's proposal or Greg's or
something else, but I can't see why we'd stick with (x << 1) | y when
better approaches are known.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-01 22:28:44 | Re: PostmasterContext survives into parallel workers!? |
Previous Message | Robert Haas | 2016-08-01 22:19:22 | Re: Combining hash values |