| From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
|---|---|
| To: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Refactor *_abbrev_convert() functions |
| Date: | 2026-02-24 14:58:38 |
| Message-ID: | CAJ7c6TO5cqH6XwDVahq=15LAfvd7AFDceiU0qJnAiRZhBPkwpg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi John,
Thanks again.
> I think it makes sense to squash 0001 and 0003 together, then 0002 and
> 0004 together.
> [...]
> 0005 doesn't buy us as much in readability since the two lines no longer match.
Makes sense.
> For the first, we should probably combine in the upper half when using
> a 64-bit hash, like this:
We could do it if you insist but I'm convinced this is redundant. In a
good hash upper 32 bits are as evenly distributed as lower ones so
this combining doesn't buy us much. This may even cause more
collisions, for values that didn't have them initially.
> Further cleanup possible now that we have 64-bit datums: MAC addresses
> are always 6 bytes, so abbreviation is no longer relevant -- datum1 is
> authoritative. That's in scope for the thread subject but also a
> bigger patch, but maybe someone would like to pick it up for PG20.
I will pick it up and submit as a separate patch a bit later.
--
Best regards,
Aleksander Alekseev
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Simplify-abbreviated-key-hashing-using-murmurhash.patch | text/x-patch | 5.7 KB |
| v3-0002-Avoid-unnecessary-type-casting-when-using-hash_an.patch | text/x-patch | 9.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Srirama Kucherlapati | 2026-02-24 15:02:01 | RE: AIX support |
| Previous Message | Andres Freund | 2026-02-24 14:39:16 | Re: More speedups for tuple deformation |