From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Andy Colson <andy(at)squeakycode(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: texteq/byteaeq: avoid detoast [REVIEW] |
Date: | 2011-01-17 19:12:57 |
Message-ID: | 1295291577.12898.1.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On mån, 2011-01-17 at 07:55 -0500, Robert Haas wrote:
> > There is, however, some desire to loosen this. Possible
> applications
> > are case-insensitive comparison and Unicode normalization. It's not
> > going to happen soon, but it may be worth considering not putting in
> an
> > optimization that we'll end up having to rip out again in a year
> > perhaps.
>
> Hmm. I hate to give up on this - it's a nice optimization for the
> cases to which it applies. Would it be possible to jigger things so
> that we can still do it byte-for-byte when case-insensitive comparison
> or Unicode normalization AREN'T in use?
Well, at the moment it's all theoretical anyway. These features aren't
on the table, and no one has implemented them.
It's quite possible, however, that if we go that way and investigate
which locales are safe for this, we might end up with the same answer as
for which locales are safe for LIKE optimization, namely none.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-01-17 19:18:36 | Re: Determining client_encoding from client locale |
Previous Message | Robert Haas | 2011-01-17 19:10:53 | Re: Review: compact fsync request queue on overflow |