Re: [PATCH] Refactor *_abbrev_convert() functions - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: [PATCH] Refactor *_abbrev_convert() functions
Date
Msg-id CAJ7c6TONaV5oXtHf2b=BfjvgL_Pb+4G-xC1whUSuyzkAyUqorQ@mail.gmail.com
Whole thread
In response to Re: [PATCH] Refactor *_abbrev_convert() functions  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: [PATCH] Refactor *_abbrev_convert() functions
List 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

pgsql-hackers by date:

Previous
From: Srirama Kucherlapati
Date:
Subject: RE: AIX support
Next
From: KAZAR Ayoub
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD