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
In-reply-to: 
 <CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com>
References: 
 <CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com>
Comments: In-reply-to John Naylor <john.naylor@enterprisedb.com>
	message dated "Wed, 14 Oct 2020 12:58:21 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3619431.1602695200.1@sss.pgh.pa.us>
Date: Wed, 14 Oct 2020 13:06:40 -0400
Message-ID: <3619432.1602695200@sss.pgh.pa.us>
Precedence: bulk

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