From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Marc-Olaf Jaschke <marc-olaf(dot)jaschke(at)s24(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
Date: | 2016-03-22 23:52:46 |
Message-ID: | CA+Tgmobzj8hobNfoVsU0Q7Lva25Oaxr23o8CYWL0Lf7eH5edBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Mar 22, 2016 at 7:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-03-22 23:58:29 | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
Previous Message | Tom Lane | 2016-03-22 23:51:15 | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-03-22 23:58:29 | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
Previous Message | Tom Lane | 2016-03-22 23:51:15 | Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |