On Thu, Aug 11, 2016 at 4:22 AM, Palle Girgensohn <gir...@pingpong.net> wrote: > But in your strxfrm code in PostgreSQL, the keys are cached, and represented > as int64:s if I remember correctly, so perhaps there is still a benefit > using the abbreviated keys? More testing is required, I guess...
ICU's ucol_nextSortKeyPart() interface is faster for this, I believe, and works because you only need the first sizeof(Datum) bytes (4 or 8 bytes). So, you have the right idea about using it (at least for the abbreviated key stuff), but the second last argument needs to be sizeof(Datum). The whole point of the abbreviated key optimization is that you can avoid pointer chasing during each and every comparison. Your test here is invalid because it doesn't involved the reuse of the keys. Often, during a sort, each item has to be compared about 20 times. I've experimented with ICU, and know it works well with this. You really need to create a scenario with a real sort, and all the conditions I describe. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
