From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible solution for LIKE optimization |
Date: | 2001-08-06 19:49:37 |
Message-ID: | 24249.997127377@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> On the other hand, LIKE *is* multibyte aware. So the hypothetical
>> non-locale-aware comparison operators would need to be aware of
>> multibyte character sets even though not aware of locale. And the
>> "add one" operator that we postulated for the LIKE index optimization
>> needs to be able to increment a multibyte character.
> Both of these are not hard if you know how strcmp operates. It would also
> be irrelevant whether "add one" to a multibyte character yields another
> valid multibyte character. strcmp doesn't care.
I imagine we can come up with a definition that makes LIKE optimization
work. I was wondering more about Hiroshi's implied question: would such
an index have any use for sorting? Or would the induced sort order (on
multibyte character sets) look too weird to be of any use?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-08-06 20:02:11 | Re: Not representable result out of too large range |
Previous Message | Peter Eisentraut | 2001-08-06 19:47:01 | Re: Possible solution for LIKE optimization |