Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] LIKE fixed(?) for non-ASCII collation orders

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andreas Degert <ad(at)papyrus-gmbh(dot)de>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] LIKE fixed(?) for non-ASCII collation orders
Date: 1999-12-31 18:50:07
Message-ID: 199912311850.NAA25467@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Yes, we always still match the LIKE.  The additional comparisons just
make the number of rows smaller.


> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
> > I have just committed what I hope is the final solution for the problem
> > of LIKE index optimization in non-ASCII locales.  indxpath.c now
> > generates both a lower and upper indexqual in all locales.  For example,
> > 	x LIKE 'foo%t'
> > will create indexqual conditions
> > 	x >= 'foo' AND x < 'fop'
> > The "<" condition is omitted only if the code is unable to produce a
> > string greater than the pattern's constant prefix.
> 
> the .. >= .. < .. condition will result in addtional matches, like 'fo ot',
> so you still have to check with LIKE. I'm using such an expression
> (without the additional LIKE) in an application, and it seems to match 
> at least everything that LIKE would match too (my users would have
> complained about missing matches, but i never did a formal test or
> evaluation).
> 
> ************
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Chris BitmeadDate: 1999-12-31 23:42:56
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
Previous:From: Peter MountDate: 1999-12-31 16:47:22
Subject: Re: [HACKERS] Happy New Year!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group