Re: Draft release notes for next week's releases - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Draft release notes for next week's releases
Date
Msg-id CAM3SWZSSA_2dW=6-ebRB0dfL0qaqJO2SYHE3sNoHMxqzqXZQyg@mail.gmail.com
Whole thread Raw
In response to Re: Draft release notes for next week's releases  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Draft release notes for next week's releases  (Peter Geoghegan <pg@heroku.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Why doesn't src/backend/port/win32/socket.c implement bind()?
Next
From: Peter Geoghegan
Date:
Subject: Re: Draft release notes for next week's releases