我可能会在标题中提出错误的问题.以下是事实:
在我们基于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
原文地址:https://www.jb51.cc/postgresql/192433.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。