| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: speed up unicode decomposition and recomposition |
| Date: | 2020-10-14 17:06:40 |
| Message-ID: | 3619432.1602695200@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
John Naylor <john(dot)naylor(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-10-14 18:58:49 | kevent latch paths don't handle postmaster death well |
| Previous Message | John Naylor | 2020-10-14 16:58:21 | speed up unicode decomposition and recomposition |