I am just an observer here, but in my understanding,
it is impossible to create an index for this type of case,
and take advantage of it, because the index would have to
be on the partial string "jon" inside the words "Tom Jones"
and "jonas."
I.e. you have to do a sequential scan of all records to find
your matches. Speed of the query, therefore, is only influenced
by the comparison speed. Is a regex search faster, or is
a LIKE search faster? My guess is that a regex search such as
~* 'jon' would be the fastest because it proceeds through the
string one character at a time, and doesn't need to convert the
text to lower case first, like a LIKE search will have to.
This depends on the regex implementation in postgres, of course.
In any case, the difference should be insignificant. I would
use the method you find more convenient.
Troy
>
> On Wed, 8 Dec 1999, Moray McConnachie wrote:
> >
> > > use: where name like '%names%'
> >
> > Except that the user specified he wanted to be able to find Tom Jones
> > and jonas from the search text jon, so you either need to use:
> >
> > where lower(name) like ('%' ¦¦ lower(searchtext) ¦¦ '%')
>
> > or something similar, which is slow unless you have an index on
> > lower(name), and even then.
> I think, this case always will be slow. Because the first '%'. I'm not
> sure about all of access methods, and comparsion operators. But this
> combination of them (btree/hash -- like) can't do indexed substr lookup.
> Is there any tricks, to do it?
>
> --
> nek;(
>
>
> ************
>
>