Re: Draft release notes for next week's releases
От | Peter Geoghegan |
---|---|
Тема | Re: Draft release notes for next week's releases |
Дата | |
Msg-id | CAM3SWZSSA_2dW=6-ebRB0dfL0qaqJO2SYHE3sNoHMxqzqXZQyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Draft release notes for next week's releases (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: Draft release notes for next week's releases
|
Список | pgsql-hackers |
On Tue, Mar 29, 2016 at 5:18 AM, Teodor Sigaev <teodor@sigaev.ru> wrote: > It's based on https://people.freebsd.org/~girgen/postgresql-icu/readme.html > work, and it was migrated to 9.5 with abbrevation keys support. > Patch in current state is not ready to commit, of course. Cool. Some quick observations on this: * We need to have a strxfrm_l_icu(), not just a strxfrm_icu(). That seems easy. * We should look into using the ucol_nextSortKeyPart() API: http://userguide.icu-project.org/collation/architecture#TOC-Partial-sort-keys I think that this could be a lot faster, because we only need a part of the collation tables in CPU cache during the generation of abbreviated keys. There is an optimization described at a low level here: https://github.com/icu-project/icu4c/blob/bbd17a792336de5873550794f8304a4b548b0663/source/i18n/collationkeys.cpp#L337 I think this could make our special strxfrm() (which only actually needs 8 bytes for abbreviated keys) a lot faster. I'd be interested to see how your Russian text example does with this extra optimization. We should not be surprised that this kind of support exists within ICU, because abbreviated keys are actually quite an old idea. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: