Re: B-Tree support function number 3 (strxfrm() optimization)
От | Robert Haas |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CA+TgmoZwQArU2hnjHb-RVot_k6udo6=JwDKWsjJiTHGnJ7WQEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
Список | pgsql-hackers |
On Tue, Sep 16, 2014 at 4:55 PM, Peter Geoghegan <pg@heroku.com> wrote: > 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. OK, good point. So committed as-is, then, except that I rewrote the comments, which I felt were excessively long for the amount of code. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: