Re: Add ASCII fast path to Unicode normalization functions - Mailing list pgsql-hackers

On Mon Sep 14, 2026 at 9:55 AM CDT, Andrew Dunstan wrote:
> Hi,
>
> A linkedin post comparing CedarDB's new Unicode normalization support
> to PostgreSQL's caught my eye [1]: same results, but a claimed 30x
> speedup on "SELECT count(*) FROM hits WHERE url IS NORMALIZED" over
> ClickBench's hits table. Most of that turned out to be down to CedarDB
> using all available threads by default versus our
> max_parallel_workers_per_gather of 2. But even at the matched thread
> count they reported a 6x edge, attributed to two things: an ASCII fast
> path (most URLs are already normalized ASCII, so you can skip decoding
> entirely), and vectorized byte scanning for the ASCII check itself.
>
> I went and looked, and unicode_is_normalized(), unicode_assigned(), and
> normalize() all decode every string to an array of char32_t codepoints,
> one utf8_to_unicode()/pg_utf_mblen() call at a time, before doing any
> real work -- including on input that's already pure ASCII. The attached
> patch adds a fast path: scan the raw bytes for anything with the high
> bit set, using the SIMD-vectorized is_valid_ascii() we already have
> (currently only used inside pg_utf8_verifystr()). If nothing is found,
> the string is trivially normalized (ASCII code points have no
> canonical or compatibility decomposition, and a combining class of
> zero) and every code point in it is assigned, so all three functions
> can return immediately.
>
> I deliberately didn't copy CedarDB's trick of comparing byte length to
> codepoint count -- getting the codepoint count means calling
> pg_mbstrlen_with_len(), exactly the scalar work this patch avoids.
> Scanning raw bytes with is_valid_ascii() instead reuses SIMD
> infrastructure we already have, and is cheaper to begin with: a single
> reduction versus a population count.
>
>
> Benchmarked with data sized to fit comfortably under shared_buffers rather
> than triggering the seqscan ring-buffer bypass, which otherwise swamps the
> comparison at larger table sizes: ~10x on pure ASCII, ~4x on an 85/15
> ASCII/non-ASCII mix, and no measurable regression on non-ASCII input
> that still needs the full decode-and-quickcheck path.
>
> Regression tests cover the ASCII-hit case for all three functions, plus
> a boundary sweep that plants a non-NFC sequence at varying offsets
> around ASCII padding, to catch any off-by-one in the SIMD-chunk/scalar-
> remainder split.
>
> [1] https://lnkd.in/p/eKUqSj73

Hey Andrew,

I saw the same LinkedIn post too, and I also started working on
a similar patch that I was benchmarking last week. So I'll provide some
review and some results that I saw.

FWIW, here is the function that I added to ascii.h:

>    /*
>     * Wrapper around is_valid_ascii() such that a string of any length can be
>     * passed in. If you know your string to have a length of a multiple of
>     * sizeof(Vector8), stick with is_valid_ascii(). It will avoid a few
>     * instructions.
>     */
>    static inline bool
>    is_all_valid_ascii(const unsigned char *s, int len)
>    {
>       int         chunk_len;
>
>       Assert(len >= 0);
>
>       if (len <= 0)
>           return true;
>
>       chunk_len = len - (len % sizeof(Vector8));
>
>       if (chunk_len > 0 && !is_valid_ascii(s, chunk_len))
>           return false;
>
>       for (int i = chunk_len; i < len; i++)
>       {
>           if (s[i] == '\0' || IS_HIGHBIT_SET(s[i]))
>               return false;
>       }
>
>       return true;
>    }

As you can see, it is basically the same as yours except this function
operates on a string of unsigned chars versus you're operating on a text
object. Not sure one is specifically better than the other, except
is_all_valid_ascii() might be more reusable than text_is_ascii(). That
can always be changed later though.

I think some of the comment for text_is_ascii() is a little verbose. For
instance, the paragraph about unicode normalization is not really
relevant to the text_is_ascii() function. It would probably fit better
where we actually do unicode normalization.

I don't think text_is_ascii() is a great function name since we
explicitly reject NUL characters. text_is_valid_ascii() is much more
indicative of what you are actually checking, and it reuses the same
wording as the is_valid_ascii() function. I would also maybe converge on
either "pure ASCII" or "valid ASCII". Not really sure if they are the
same, but I see both mentioned in the codebase.

Here are my benchmark findings, which concur with your analysis:

> The benchmarks below use the ClickBench hits table (100M rows), sampled
> into four tables. Times are medians (ms) of 5 timed runs after 2 warm-up
> runs on a release build (-Dbuildtype=release -Dcassert=false), with
> max_parallel_workers_per_gather = 0 and all data cached in memory. The
> baseline is unpatched master as of a12600b762c.
>
> Three tables come from the URL column:
>
> - bench_ascii: 20M ASCII-only URLs.
> - bench_nonascii: 14,963,181 URLs containing at least one non-ASCII byte.
>   These are still mostly ASCII; a URL with one Cyrillic path segment
>   lands here.
> - bench_mixed: 20M URLs, unfiltered, so ~15% contain at least one
>   non-ASCII byte, which is the natural ratio of the dataset.
>
> The URL column has no rows that are predominantly non-ASCII rather than
> merely containing some, so the fourth table comes from the Title column:
>
> - bench_cyrillic: 5M Russian titles. This is just about the worst case
>   for this patch. This patch optimistically looks for ASCII characters.
>   Russian lacks ASCII characters, except for spaces and punctuation, as
>   far as I know.
>
> unicode_is_normalized() - SELECT count(*) FROM <table> WHERE <text> IS NORMALIZED;
> table             baseline (ms)  patched (ms)   speedup
> bench_ascii             19329.5        1812.2    10.67x
> bench_nonascii          45370.8       42319.4     1.07x
> bench_mixed             26918.0       10218.9     2.63x
> bench_cyrillic           4797.6        4978.1     0.96x
> bench_cyrillic*          4827.9        4861.2     0.99x
>
> unicode_assigned() - SELECT count(*) FROM <table> WHERE unicode_assigned(<text>);
> table             baseline (ms)  patched (ms)   speedup
> bench_ascii              8889.9        1586.1     5.60x
> bench_nonascii          24269.1       21474.7     1.13x
> bench_mixed             13021.6        5620.4     2.32x
> bench_cyrillic           6015.9        6210.7     0.97x
> bench_cyrillic*          6071.0        6134.4     0.99x
>
> unicode_normalize_func() - SELECT count(normalize(<text>)) FROM <table>;
> table             baseline (ms)  patched (ms)   speedup
> bench_ascii             59292.9        1714.4    34.59x
> bench_nonascii         147948.4      145031.3     1.02x
> bench_mixed             86104.6       31805.2     2.71x
> bench_cyrillic          14175.4       14553.5     0.97x
> bench_cyrillic*         14467.5       14326.5     1.01x
>
> bench_cyrillic* is basically the same as bench_cyrillic, except that
> master and the patched tree were compiled with -falign-functions=64
> -falign-loops=64. I found that with the changes the hot loops could
> straddle a 64-bit instruction fetch boundary.

In essence, I completely agree with your findings. Note that I did not
bump shared_buffers like you did, which was likely a very smart call.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)