很早的一篇文字, 今天遇到了问题,开发问我怎么解决, 又翻出来, PG 的优越性比 ORACLE SQL SERVER MYSQL 高明的地方,就体现在下方的文字
正文：
本来上次是写过这个PostgreSQL 的功能的，但上次在一个论坛里面发现其实大家对这个功能认识上是有误区的，所示这次是的详细的一次文字。
功能很简单的就是模糊查询，类似 select * from table where column1 like ‘%PG牛逼%’；然后走一个靠谱的索引的查询，ORACLE 打死他都不行，当然可以走全文索引，那MYSQL, SQL SERVER 人家也不干，人家也有这功能。
pg_trgm本身是不包含在PostgreSQL 的源码安装中的，当然是插件的方式安装，安装上是很简单的，具体请百度（弄湿了我可不管）
进入到你的数据库，create extension pg_trgm；就OK 了
我在论坛中发现的第一个问题，是说建立这样的模糊查询，仅仅建立btree 索引就可以了，但pg_trgm 只支持两种索引Gist and Gin, 这两种索引。（这可不是我说的，官方的白纸黑字）
所以说正确的针对一个列的索引，是要建立两个索引的，一个是BTREE 索引，一个是 GIN 或 Gist 索引，两种索引面对的“客户”是不同的。
那我们来看看到底他是怎么工作的
首先我们先生成一个表用来测试
创建一个存储过程用来插入测试数据
代码语言：javascript复制create or replace function data_produce(int) returns text as $$
declare
res text;
begin
if $1 >=1 then
select string_agg(chr(19968 (random()*20901)::int), '') into res from generate_series(1,$1);
return res;
end if;
return null;
end;
$$ language plpgsql strict; 
insert into test_pg_trgm (search) select data_produce(20) from generate_series(1,1110000);执行后生成我们本次要测试的数据10万条
下面我们创建索引了，创建GIN 索引
创建索引中系统报错，这是由于还没有创建相关的扩展
添加了这些扩展后我们就可以建立相关的索引
我们可以看到查询已经走了索引，并且查询时间1ms
那如果我们没有这个索引会怎么样，这条语句慢了 48倍并且只能和ORACLE SQL SERVER , MYSQL一样走了全表扫描。
OK 如果已经体会到了PG 在模糊查询中的厉害之处，群里有人问的第二个问题是 GIN VS GIST 那种索引更好
这也是一个热门的问题？
下面也做一个测试，（但不证明GIN 比 GIST 性能强），我们建立一个gist的索引，也提通过查询来进行模糊方式的查询
图中的时间 12ms ，比全表扫描快了4倍，比GIN 慢了12倍
当然这里并不是说 GIST 不如GIN ，具体的索引有不同的使用场景。（做人办事都的客观）
最后，我们来证明一下，普通的运算方式对于GIST GIN 索引是无效的，所以我们对某个字段必须建立两个索引 BTREE AND GIST OR GIN。
下图整体的证明了上面的立论。这里就不解释了
最后回归题目，PG 为何“大爱”程序员，想想一个不靠谱的模糊需求能把一个程序员弄得“五脊六瘦”（具体是那个地方的方言请脑补），而PG 可以将这个事情化解，难道还不是程序员的“大爱”。
