Re: speed up unicode normalization quick check

On Sun, Oct 11, 2020 at 6:27 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> And applied. I did some more micro benchmarking with the quick
> checks, and the numbers are cool, close to what you mentioned for the
> quick checks of both NFC and NFKC.
>

Thanks for confirming.

> Just wondering about something in the same area, did you look at the
> decomposition table?

Hmm, I hadn't actually, but now that you mention it, that looks worth
optimizing that as well, since there are multiple callers that search that
table -- thanks for the reminder. The attached patch was easy to whip up,
being similar to the quick check (doesn't include the pg_hton32 fix). I'll
do some performance testing soon. Note that a 25kB increase in size could
be present in frontend binaries as well in this case. While looking at
decomposition, I noticed that recomposition does a linear search through
all 6600+ entries, although it seems only about 800 are valid for that.
That could be optimized as well now, since with hashing we have more
flexibility in the ordering and can put the recomp-valid entries in front.
I'm not yet sure if it's worth the additional complexity. I'll take a look
and start a new thread.

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company