Thread: like and optimization
Hello, I didn't know pgsql-sources close, so I wrote this code just as example of idea. Can somebody review and make patch for pgsql? (if this idea is good, of cource). like-optimization is working only with ASCII, but it is simple to fix. This programm makes greater string(I tested with KOI8-R): -- Bye Juriy Goloveshkin
Attachment
Juriy Goloveshkin <juriy@avias.com> writes:
> Hello, I didn't know pgsql-sources close,
> so I wrote this code just as example of idea.
> Can somebody review and make patch for pgsql?
AFAICT this only deals with the issue of single-byte characters that
sort in an order different from their numeric order. The existing
make_greater_string() code already deals with that case. Where it
falls down is cases where sorting is context-dependent (multi-pass
sort rules, digraphs, things like that). But I don't see anything
here that would make such cases work.
If you're trying to tell us that the 7.0.* code works correctly for
KOI8-R locale, we'd be glad to re-enable LIKE optimization for that
locale ...
regards, tom lane
On Sun, 21 Jan 2001 00:25:17 +0000 (UTC), Tom Lane <tgl@sss.pgh.pa.us> wrote: >Juriy Goloveshkin <juriy@avias.com> writes: >> Hello, I didn't know pgsql-sources close, >> so I wrote this code just as example of idea. >> Can somebody review and make patch for pgsql? > >AFAICT this only deals with the issue of single-byte characters that >sort in an order different from their numeric order. The existing >make_greater_string() code already deals with that case. Where it >falls down is cases where sorting is context-dependent (multi-pass >sort rules, digraphs, things like that). But I don't see anything >here that would make such cases work. > >If you're trying to tell us that the 7.0.* code works correctly for >KOI8-R locale, we'd be glad to re-enable LIKE optimization for that >locale ... Hello, I have no knowledge of postgres internals at all (yet !), and I'm not quite sure what this thread is exactly about. But if anybody thinks that selects with LIKE on indexed columns with single-byte non-ASCII characters are working OK: they are not !! See my posting and following thread "7.0.3 reproduceable serious select error" from a couple of days ago. I made a reproduceable example of things going wrong with a "en_US" locale which is the widely-used (single-byte) ISO-8859-1 Latin 1 charset. Please excuse me if this has nothing to do with what you are talking about. I'm just very eager to get rid of this (for our application) extremely nasty bug ! friendly greetings,Rob van Nieuwkerk
robn@verdi.et.tudelft.nl (Rob van Nieuwkerk) writes:
> But if anybody thinks that selects with LIKE on indexed columns with
> single-byte non-ASCII characters are working OK: they are not !! See my
> posting and following thread "7.0.3 reproduceable serious select error"
> from a couple of days ago.
Yes, we know :-(. That's why that optimization is currently disabled
for non-ASCII locales in 7.1. Juriy appears to be saying that it does
work OK in KOI8-R locale.
> I made a reproduceable example of things going wrong with a "en_US"
> locale which is the widely-used (single-byte) ISO-8859-1 Latin 1 charset.
en_US uses multi-pass collation rules. It's those collation rules, not
the charset per se, that causes the problem.
regards, tom lane