Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
От | Robert Haas |
---|---|
Тема | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
Дата | |
Msg-id | CA+Tgmobzj8hobNfoVsU0Q7Lva25Oaxr23o8CYWL0Lf7eH5edBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)
|
Список | pgsql-bugs |
On Tue, Mar 22, 2016 at 7:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >>> I was a little worried that it was too much to hope for that all libc >>> vendors on earth would ship a strxfrm() implementation that was actually >>> consistent with strcoll(), and here we are. > > BTW, the glibc discussion starting here: > https://sourceware.org/ml/libc-alpha/2015-09/msg00196.html > should put substantial fear in us about the advisability of putting strxfrm > results on-disk, as I understand we're now doing in btrees. No. Peter proposed that, but it hasn't actually been done. This certainly makes that sound inadvisable, though. We are, however, putting indexes on disk whose ordering was determined partly by the result of strxfrm() comparisons. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: