我可能会在标题中提出错误的问题.以下是事实：
在我们基于Django的站点的管理界面上进行客户查询时,我的客户服务人员一直在抱怨响应时间慢.
我们正在使用Postgres 8.4.6.我开始记录慢查询,并发现了这个罪魁祸首：
SELECT COUNT(*) FROM "auth_user" WHERE UPPER("auth_user"."email"::text) LIKE UPPER(E'%deyk%')
此查询运行时间超过32秒.这是EXPLAIN提供的查询计划：
QUERY PLAN
Aggregate (cost=205171.71..205171.72 rows=1 width=0)
-> Seq Scan on auth_user (cost=0.00..205166.46 rows=2096 width=0)
Filter: (upper((email)::text) ~~ '%DEYK%'::text)
因为这是Django ORM从Django Admin应用程序生成的Django QuerySet生成的查询,所以我对查询本身没有任何控制权.索引似乎是逻辑解决方案.我尝试创建一个索引来加快速度,但它没有什么区别：
CREATE INDEX auth_user_email_upper ON auth_user USING btree (upper(email::text))
我究竟做错了什么？如何加快此查询？
Postgresql 8.4中没有对LIKE / ILIKE的索引支持 – 除了
left anchored search terms.
Postgresql 9.1或更高版本在扩展pg_trgm中提供了新功能,可以使用提供的运算符类为任何具有GIN或GiST索引的表单启用LIKE / ILIKE表达式(或简单正则表达式,运算符〜和朋友)的索引支持.
每个数据库安装一次扩展：
CREATE EXTENSION pg_trgm;
示例GIN索引：
CREATE INDEX tbl_col_gin_trgm_idx ON tbl USING gin (col gin_trgm_ops);
此相关答案中的更多信息和链接：
模式匹配和适当指数概述：
> Pattern matching with LIKE,SIMILAR TO or regular expressions in PostgreSQL
