Re: texteq/byteaeq: avoid detoast [REVIEW]

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.

In response to

Browse pgsql-hackers by date

  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