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  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: speed up unicode decomposition and recomposition
Следующее
От: Tom Lane
Дата:
Сообщение: kevent latch paths don't handle postmaster death well