Use mbsnrtowcs() in char2wchar() to avoid temporary string copies

From: David Geier <geidav(dot)pg(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Use mbsnrtowcs() in char2wchar() to avoid temporary string copies
Date: 2026-10-07 15:01:00
Message-ID: 955250df-3abd-4b2b-9779-01e6afc60a4b@googlemail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

While playing around with optimizing trigram detection and splitting in
generate_trgm_only(), I found that char2wchar() creates a string copy
via pstrdup() because mbstowcs() requires the input string to be
null-terminated. Switching to mbsnrtowcs() saves 2-3% of the total
CREATE INDEX statement.

Seems like an easy win, or is there a good reason not to use
mbsnrtowcs() on platforms where it is supported?

The patch needs a bit more work to remove mbstowcs_l(), including the
build system part, and possibly doing the build system part for
mbsnrtowcs().

Beyond that, why do a lot of (all?) string conversion functions not
write anything into the output buffer if it turned out to be too small?
That requires creating a temp buffer that the result is written into to
then copy it into the output buffer if its big enough, e.g.
strlower_libc_mb() does the following:

max_size = curr_char * pg_database_encoding_max_length();
result = palloc(max_size + 1);
result_size = wchar2char(result, workspace, max_size + 1, loc);

if (destsize >= result_size + 1)
{
memcpy(dest, result, result_size);
dest[result_size] = '\0';
}

The problem with that is that even if the output buffer is big enough,
the function always needs to palloc() + memcpy() which would be great to
avoid as most places can simple allocate num_characters *
pg_database_encoding_max_length() many characters upfront and be done
with it.

On top of that we could think about allowing to call the conversion
functions iteratively. The call site could realloc as needed and then
call the conversion function only on the not-yet-converted data instead
of converting everything again.

--
David Geier

Attachment Content-Type Size
v1-0001-Avoid-string-copy-in-char2wchar.patch text/x-patch 1.7 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-10-07 15:26:51 Re: REPACK (CONCURRENTLY) might keep dropped-column data
Previous Message Shlok Kyal 2026-10-07 14:39:59 Re: Parallel Apply