| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Marc-Olaf Jaschke <marc-olaf(dot)jaschke(at)s24(dot)com> |
| Subject: | Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
| Date: | 2016-03-23 19:04:37 |
| Message-ID: | CA+TgmoaiH=KHfrH=+m7Zxy7OLHeNVdEA2S=4u3JbJyRzu3d4DQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Mar 23, 2016 at 3:01 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Wed, Mar 23, 2016 at 11:56 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I think that something like the attached would be a reasonable
>> approach to the problem. If we later decide this is altogether
>> hopeless, we can do a more thorough job removing the code that can be
>> reached when collate_c && abbreviate, but let's not do that right now.
>
> This patch looks good to me.
>
> I think that disabling abbreviation when the C collation is in makes
> no sense, though.
But the patch doesn't do that, right?
> This has nothing to do with abbreviation as such,
> and everything to do with glibc.
Yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-03-23 19:07:27 | Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
| Previous Message | Peter Geoghegan | 2016-03-23 19:01:36 | Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-03-23 19:07:27 | Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
| Previous Message | Robert Haas | 2016-03-23 19:01:44 | Re: Relation extension scalability |