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 15:05:59
Message-ID: CAJ7c6TONaV5oXtHf2b=BfjvgL_Pb+4G-xC1whUSuyzkAyUqorQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v4-0002-Avoid-unnecessary-type-casting-when-using-hash_an.patch text/x-patch 9.3 KB
v4-0001-Simplify-abbreviated-key-hashing-using-murmurhash.patch text/x-patch 5.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KAZAR Ayoub 2026-02-24 15:07:38 Re: Speed up COPY FROM text/CSV parsing using SIMD
Previous Message Srirama Kucherlapati 2026-02-24 15:02:01 RE: AIX support