Re: B-Tree support function number 3 (strxfrm() optimization)
От | Peter Geoghegan |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CAM3SWZSPtZbWPamZOstG0ggirxn4-42g6HRSsjxi8kMN==4dpw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
Список | pgsql-hackers |
On Tue, Sep 16, 2014 at 1:45 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Even though our testing seems to indicate that the memcmp() is > basically free, I think it would be good to make the effort to avoid > doing memcmp() and then strcoll() and then strncmp(). Seems like it > shouldn't be too hard. Really? The tie-breaker for the benefit of locales like hu_HU uses strcmp(), not memcmp(). It operates on the now-terminated copies of strings. There is no reason to think that the strings must be the same size for that strcmp(). I'd rather only do the new opportunistic "memcmp() == 0" thing when len1 == len2. And I wouldn't like to have to also figure out that it's safe to use the earlier result, because as it happens len1 == len2, or any other such trickery. The bug fix that added the strcmp() tie-breaker was committed in 2005. PostgreSQL had locale support for something like 8 years prior, and it took that long for us to notice the problem. I would suggest that makes the case for doing anything else pretty marginal. In the bug report at the time, len1 != len2 anyway. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: