Re: LIKE search and performance

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Alexander Staubo <alex(at)purefiction(dot)net>
Cc: Andy <frum(at)ar-sd(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: LIKE search and performance
Date: 2007-05-24 18:50:29
Message-ID: 4655DE75.4080506@mansionfamily.plus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alexander Staubo wrote:
> On 5/23/07, Andy <frum(at)ar-sd(dot)net> wrote:
>> An example would be:
>> SELECT * FROM table
>> WHERE name like '%john%' or street like
>> '%srt%'
>>
>> Anyway, the query planner always does seq scan on the whole table and
>> that
>> takes some time. How can this be optimized or made in another way to be
>> faster?
>
> There's no algorithm in existence that can "index" arbitrary
> substrings the way you think. The only rational way to accomplish this
> is to first break the text into substrings using some algorithm (eg.,
> words delimited by whitespace and punctuation), and index the
> substrings individually.
That seems rather harsh. If I'd put an index on each of these colomns
I'd certainly
expect it to use the indices - and I'm pretty sure that Sybase would.
I'd expect
it to scan the index leaf pages instead of the table itself - they
should be much
more compact and also likely to be hot in cache.

Why *wouldn't* the planner do this?

James

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Magnus Hagander 2007-05-24 19:23:55 Re: LIKE search and performance
Previous Message Andy 2007-05-24 07:03:42 Re: LIKE search and performance