| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unicode normalization SQL functions |
| Date: | 2020-02-19 20:23:12 |
| Message-ID: | b0c0dbbd-9142-6bf8-4483-3a46360c55d3@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-02-17 20:08, Daniel Verite wrote:
> Concerning execution speed, there's an excessive CPU usage when
> normalizing into NFC or NFKC. Looking at pre-existing code, it looks
> like recompose_code() in unicode_norm.c looping over the
> UnicodeDecompMain array might be very costly.
Yes, this is a known issue and I think room for future optimization work.
> Another point is that the ICU-based implementation appears
> to be significantly faster in all cases, which makes me wonder
> why ICU builds should not just use ICU instead of the PG-core
> implementation.
That would require linking libpq to ICU (for SASLprep), and in general
would either make ICU required or require maintaining multiple
implementations. I don't think we're there yet.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-02-19 20:38:21 | Re: error context for vacuum to include block number |
| Previous Message | Misha Patel | 2020-02-19 20:13:01 | Open Source Hackathon Mentorship Invitation |