Re: [PATCH] Refactor *_abbrev_convert() functions

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

In response to

Responses

Browse pgsql-hackers by date

  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