Re: [PATCH] Refactor *_abbrev_convert() functions

Aleksander Alekseev <aleksander@tigerdata.com>

From: Aleksander Alekseev <aleksander@tigerdata.com>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Cc: John Naylor <johncnaylorls@gmail.com>
Date: 2026-02-24T15:05:59Z
Lists: pgsql-hackers

Attachments

Hi,

> 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.

0002 had a wrong commit message due to a mistake during squashing.
Here is a corrected patch.

-- 
Best regards,
Aleksander Alekseev