Re: sequential scan performance - Mailing list pgsql-performance

From Oleg Bartunov
Subject Re: sequential scan performance
Date
Msg-id Pine.GSO.4.62.0505292342170.1721@ra.sai.msu.su
Whole thread Raw
In response to sequential scan performance  (Michael Engelhart <mengelhart@mac.com>)
Responses Re: sequential scan performance  (Michael Engelhart <mengelhart@mac.com>)
List pgsql-performance
Michael,

I'd recommend our contrib/pg_trgm module, which provides
trigram based fuzzy search and return results ordered by similarity
to your query.  Read http://www.sai.msu.su/~megera/postgres/gist/pg_trgm/README.pg_trgm
for more details.

Oleg
On Sun, 29 May 2005, Michael Engelhart wrote:

> Hi -
>
> I have a table of about 3 million rows of city "aliases" that I need to query
> using LIKE - for example:
>
> select * from city_alias where city_name like '%FRANCISCO'
>
>
> When I do an EXPLAIN ANALYZE on the above query, the result is:
>
> Seq Scan on city_alias  (cost=0.00..59282.31 rows=2 width=42) (actual
> time=73.369..3330.281 rows=407 loops=1)
>   Filter: ((name)::text ~~ '%FRANCISCO'::text)
> Total runtime: 3330.524 ms
> (3 rows)
>
>
> this is a query that our system needs to do a LOT.   Is there any way to
> improve the performance on this either with changes to our query or by
> configuring the database deployment?   We have an index on city_name but when
> using the % operator on the front of the query string postgresql can't use
> the index .
>
> Thanks for any help.
>
> Mike
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>   (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

     Regards,
         Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Select performance vs. mssql
Next
From: "Eric Lauzon"
Date:
Subject: OID vs overall system performances on high load