On Sun, Oct 11, 2020 at 6:27 AM Michael Paquier <michael@paquier.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.
