Re: speed up unicode decomposition and recomposition
| От | Tom Lane |
|---|---|
| Тема | Re: speed up unicode decomposition and recomposition |
| Дата | |
| Msg-id | 3619432.1602695200@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | speed up unicode decomposition and recomposition (John Naylor <john.naylor@enterprisedb.com>) |
| Ответы |
Re: speed up unicode decomposition and recomposition
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: