From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: speed up unicode decomposition and recomposition
Date: Wed, 14 Oct 2020 13:06:40 -0400
Message-ID: <3619432.1602695200@sss.pgh.pa.us> (raw)
In-Reply-To: <CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com>
References: <CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com>
John Naylor <john.naylor@enterprisedb.com> writes:
> Some other considerations:
> - As I alluded above, this adds ~26kB to libpq because of SASLPrep. Since
> the decomp array was reordered to optimize linear search, it can no longer
> be used for binary search. It's possible to build two arrays, one for
> frontend and one for backend, but that's additional complexity. We could
> also force frontend to do a linear search all the time, but that seems
> foolish. I haven't checked if it's possible to exclude the hash from
> backend's libpq.
IIUC, the only place libpq uses this is to process a password-sized string
or two during connection establishment. It seems quite silly to add
26kB in order to make that faster. Seems like a nice speedup on the
backend side, but I'd vote for keeping the frontend as-is.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, john.naylor@enterprisedb.com
Subject: Re: speed up unicode decomposition and recomposition
In-Reply-To: <3619432.1602695200@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox