diff options
author | Michael Paquier <michael@paquier.xyz> | 2020-10-23 11:05:46 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2020-10-23 11:05:46 +0900 |
commit | 783f0cc64dcc05e3d112a06b1cd181e5a1ca9099 (patch) | |
tree | ea1b0834526609807e36d5618a8ccb14147bdb1b /src/backend/executor/execMain.c | |
parent | 7d6d6bce43c60bb7b77237e2cc6ab845646b911f (diff) | |
download | postgresql-783f0cc64dcc05e3d112a06b1cd181e5a1ca9099.tar.gz postgresql-783f0cc64dcc05e3d112a06b1cd181e5a1ca9099.zip |
Improve performance of Unicode {de,re}composition in the backend
This replaces the existing binary search with two perfect hash functions
for the composition and the decomposition in the backend code, at the
cost of slightly-larger binaries there (35kB in libpgcommon_srv.a). Per
the measurements done, this improves the speed of the recomposition and
decomposition by up to 30~40 times for the NFC and NFKC conversions,
while all other operations get at least 40% faster. This is not as
"good" as what libicu has, but it closes the gap a lot as per the
feedback from Daniel Verite.
The decomposition table remains the same, getting used for the binary
search in the frontend code, where we care more about the size of the
libraries like libpq over performance as this gets involved only in code
paths related to the SCRAM authentication. In consequence, note that
the perfect hash function for the recomposition needs to use a new
inverse lookup array back to to the existing decomposition table.
The size of all frontend deliverables remains unchanged, even with
--enable-debug, including libpq.
Author: John Naylor
Reviewed-by: Michael Paquier, Tom Lane
Discussion: https://postgr.es/m/CAFBsxsHUuMFCt6-pU+oG-F1==CmEp8wR+O+bRouXWu6i8kXuqA@mail.gmail.com
Diffstat (limited to 'src/backend/executor/execMain.c')
0 files changed, 0 insertions, 0 deletions