Re: Add ASCII fast path to Unicode normalization functions

On 2026-09-17 Th 6:46 PM, Tristan Partin wrote:
> 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 don't have a strong opinion about it. It would just mean that you
would migrate the VARDATA_ANY etc. stuff to the call sites.

>
> 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.

Fair point

>
> 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.

I'm not fixed on the name, but we might want something different if we
go with Bilal's useful optimization from upthread.

>
> 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.

When time permits I'll send a new version, incorporating your review and
Bilal's suggestion.

Thanks for the review!

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com