atom feed6 messages in org.postgresql.pgsql-sqlRe: [SQL] making 'like' queries quicker
FromSent OnAttachments
adminDec 17, 1999 2:04 pm 
adminDec 18, 1999 6:52 am 
Peter EisentrautDec 18, 1999 8:13 am 
tj...@tksoft.comDec 18, 1999 1:53 pm 
Tom LaneDec 18, 1999 2:27 pm 
tj...@tksoft.comDec 19, 1999 2:20 am 
Subject:Re: [SQL] making 'like' queries quicker
From:Tom Lane (
Date:Dec 18, 1999 2:27:41 pm

"" <> writes:

A general rule of thumb is that indexes only work on exact matches.

Troy's rule of thumb is correct, but there's an important additional property of some types of indexes: you can scan them in order (for whatever kind of "order" is imposed by the index comparison operator). Postgres' btree indexes work that way, but hash indexes don't.

An ordered index can be used to process inequalities and range queries as well as exact-match queries. For example, with a btree index you can do something like WHERE lastname >= 'Smith' AND lastname <= 'Szekely' fairly efficiently: you scan the portion of the index falling between the given limits, and then extract the main-table records pointed to by those index entries.

Therefore, it's practical to use a btree index to speed up match queries that require a match at the start of the string. For example, given WHERE lastname LIKE 'Smith%' Postgres will generate additional clauses lastname >= 'Smith' AND lastname <= 'Smith\377' which can be used with a btree index to restrict the number of records that have to be looked at. You still have to do the LIKE comparison, in general (consider LIKE 'Smith%Jr') but you don't have to do it for every record in the table.

There isn't any obvious way to apply this trick for an unanchored match, though (as in LIKE '%Smith%').

However, if you are actually interested in searching for whole words, you could consider making an index that lists all of the whole words in your target field, and doing an exact match with that index. See contrib/fulltextindex in the Postgres distribution for an example.