| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Combining hash values |
| Date: | 2016-08-01 15:22:04 |
| Message-ID: | 6688.1470064924@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> I was originally going to suggest using a crc to combine but iirc we
> changed hash_any() a while back and decided against using crc. I don't know
> if that was wise but wouldn't want to suggest relitigating that.
Nah, CRCs are designed to solve a different problem, ie detecting
single-bit and burst errors with high probability. In particular, I don't
think they make any particular promises with respect to spreading changes
into all bits of the result. That's important for our hash functions
because we usually take just the lowest N bits of the result as being
adequately randomized.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2016-08-01 15:25:10 | PostgreSQL 10 kick-off |
| Previous Message | Tom Lane | 2016-08-01 15:15:23 | Re: Broken order-of-operations in parallel query latch manipulation |