Re: speed up unicode normalization quick check

John Naylor <john.naylor@2ndquadrant.com>

From: John Naylor <john.naylor@2ndquadrant.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-29T03:54:39Z
Lists: pgsql-hackers
On Fri, May 29, 2020 at 5:59 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
> > On May 21, 2020, at 12:12 AM, John Naylor <john.naylor@2ndquadrant.com> wrote:

> > very picky in general. As a test, it also successfully finds a
> > function for the OS "words" file, the "D" sets of codepoints, and for
> > sets of the first n built-in OIDs, where n > 5.
>
> Prior to this patch, src/tools/gen_keywordlist.pl is the only script that uses PerfectHash.  Your patch adds a second.  I'm not convinced that modifying the PerfectHash code directly each time a new caller needs different multipliers is the right way to go.

Calling it "each time" with a sample size of two is a bit of a
stretch. The first implementation made a reasonable attempt to suit
future uses and I simply made it a bit more robust. In the text quoted
above you can see I tested some scenarios beyond the current use
cases, with key set sizes as low as 6 and as high as 250k.

> Could you instead make them arguments such that gen_keywordlist.pl, generate-unicode_combining_table.pl, and future callers can pass in the numbers they want?  Or is there some advantage to having it this way?

That is an implementation detail that callers have no business knowing about.

-- 
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Review format of code generated by PerfectHash.pm

  2. Fix compilation warning in unicode_norm.c

  3. Use perfect hash for NFC and NFKC Unicode Normalization quick check

  4. Improve set of candidate multipliers for perfect hash function generation

  5. Further improve pgindent's list of file exclusions.