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
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 |