GiST的意思是通用的搜索树(Generalized Search Tree)。 它是一种平衡树结构的访问方法,在系统中作为一个基本模版,可以使用它实现任意索引模式。B-trees, R-trees和许多其它的索引模式都可以用GiST实现。

上面一段高能的官方解释有点难以理解,暂时也不需要使用Gist实现其他的索引模式,就简单的介绍下Gist索引如何使用,

与Btree索引比较的优缺点:

优点:

Gist索引适用于多维数据类型和集合数据类型,和Btree索引类似,同样适用于其他的数据类型。和Btree索引相比,Gist多字段索引在查询条件中包含索引字段的任何子集都会使用索引扫描,而Btree索引只有查询条件包含第一个索引字段才会使用索引扫描。

缺点:

Gist索引创建耗时较长,占用空间也比较大。

测试表

test=# create table tbl_index(a bigint,b timestamp without time zone,c varchar(12));
CREATE TABLE
test=# insert into tbl_index (a,b,c) select generate_series(1,3000000),clock_timestamp()::timestamp(0) without time zone,'got u';
INSERT 0 3000000
test=# \timing
Timing is on.

创建Gist索引的前提是已经编译并安装了Gist的扩展,因为我源码编译时已经编译安装了所有的扩展,所以这里只需要在数据库中创建扩展即可。

test=# create extension btree_gist;
CREATE EXTENSION
Time: 774.131 ms

创建索引

test=# create index idx_gist_tbl_index_a_b on tbl_index using gist(a,b);
CREATE INDEX
Time: 168595.321 ms

示例1.使用字段a查询

test=# explain analyze select * from tbl_index where a=3000000;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..21395.10 rows=1 width=22) (actual time=310.514..310.517 rows=1 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Parallel Seq Scan on tbl_index (cost=0.00..20395.00 rows=0 width=22) (actual time=289.432..289.433 rows=0 loops=3)
Filter: (a = 3000000)
Rows Removed by Filter: 1000000
Planning time: 0.119 ms
Execution time: 310.631 ms
(8 rows) Time: 311.505 ms
test=# explain analyze select * from tbl_index where a='';
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Index Scan using idx_gist_tbl_index_a_b on tbl_index (cost=0.29..8.30 rows=1 width=22) (actual time=0.104..0.105 rows=1 loops=1)
Index Cond: (a = ''::bigint)
Planning time: 0.109 ms
Execution time: 0.297 ms
(4 rows) Time: 1.124 ms

以上两条SQL语句的区别在于第一条SQL语句按照a的类型bigint去查询,而第二条SQL语句却将bigint转成char类型查询,但是结果显示char类型的查询(索引扫描)性能远高于bigint的查询(全表扫描)性能,怀疑是不是创建索引时将bigint转成char类型了(只是猜测),反正Gist索引查询最好使用char。

示例2.使用字段b查询

test=# explain analyze select * from tbl_index where b='2016-06-29 14:54:00';
QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------
---------
Bitmap Heap Scan on tbl_index (cost=3373.54..10281.04 rows=171000 width=22) (actual time=37.200..53.564 rows=172824 loops=1)
Recheck Cond: (b = '2016-06-29 14:54:00'::timestamp without time zone)
Heap Blocks: exact=276
-> Bitmap Index Scan on idx_gist_tbl_index_a_b (cost=0.00..3330.79 rows=171000 width=0) (actual time=37.139..37.139 rows=172824
loops=1)
Index Cond: (b = '2016-06-29 14:54:00'::timestamp without time zone)
Planning time: 0.343 ms
Execution time: 60.843 ms
(7 rows) Time: 62.359 ms

该查询不包含第一个索引字段,但是仍使用索引扫描,而此条件下Btree索引只能全表扫描。

示例3.使用a and b查询

test=# explain analyze select * from tbl_index where a='' and b='2016-06-29 14:54:00';
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Index Scan using idx_gist_tbl_index_a_b on tbl_index (cost=0.29..8.31 rows=1 width=22) (actual time=0.114..0.115 rows=1 loops=1)
Index Cond: ((a = ''::bigint) AND (b = '2016-06-29 14:54:00'::timestamp without time zone))
Planning time: 0.376 ms
Execution time: 0.258 ms
(4 rows) Time: 1.747 ms

示例4.使用a or b查询

test=# explain analyze select * from tbl_index where a='' or b='2016-06-29 14:54:00';
QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------
---------------
Bitmap Heap Scan on tbl_index (cost=3420.58..10755.60 rows=171001 width=22) (actual time=31.142..49.728 rows=172824 loops=1)
Recheck Cond: ((a = ''::bigint) OR (b = '2016-06-29 14:54:00'::timestamp without time zone))
Heap Blocks: exact=276
-> BitmapOr (cost=3420.58..3420.58 rows=171001 width=0) (actual time=31.083..31.083 rows=0 loops=1)
-> Bitmap Index Scan on idx_gist_tbl_index_a_b (cost=0.00..4.29 rows=1 width=0) (actual time=0.100..0.100 rows=1 loops=1)
Index Cond: (a = ''::bigint)
-> Bitmap Index Scan on idx_gist_tbl_index_a_b (cost=0.00..3330.79 rows=171000 width=0) (actual time=30.981..30.981 rows=1
72824 loops=1)
Index Cond: (b = '2016-06-29 14:54:00'::timestamp without time zone)
Planning time: 0.143 ms
Execution time: 57.193 ms
(10 rows) Time: 58.067 ms

使用and和or查询虽然也是索引扫描,但是和Btree索引相比并没有性能提升。

比较Gist索引和Btree索引的创建耗时和大小

btree索引耗时:

test=# create index idx_btree_tbl_index_a_b on tbl_index using btree(a,b);
CREATE INDEX
Time: 5217.976 ms

Gist索引耗时从上面看到是168595.321 ms,是Btree索引耗时的32倍。

大小比较,结果显示Gist索引是Btree索引的3倍多。

test=# select relname,pg_size_pretty(pg_relation_size(oid)) from pg_class where relname like 'idx_%_tbl_index_a_b';
relname | pg_size_pretty
-------------------------+----------------
idx_gist_tbl_index_a_b | 281 MB
idx_btree_tbl_index_a_b | 89 MB
(2 rows) Time: 4.068 ms

postgresql----Gist索引的更多相关文章

  1. 浅谈PostgreSQL的索引

    1. 索引的特性 1.1 加快条件的检索的特性 当表数据量越来越大时查询速度会下降,在表的条件字段上使用索引,快速定位到可能满足条件的记录,不需要遍历所有记录. create table t(id i ...

  2. (转)浅谈PostgreSQL的索引

    1. 索引的特性 1.1 加快条件的检索的特性 当表数据量越来越大时查询速度会下降,在表的条件字段上使用索引,快速定位到可能满足条件的记录,不需要遍历所有记录. create table t(id i ...

  3. 对PostgreSQL数据库的hstore类型建立GisT索引的实验

    磨砺技术珠矶,践行数据之道,追求卓越价值回到上一级页面:PostgreSQL基础知识与基本操作索引页    回到顶级页面:PostgreSQL索引页[作者 高健@博客园  luckyjackgao@g ...

  4. PostgreSQL的索引选型

    PostgreSQL里面给全文检索或者模糊查询加索引提速的时候,一般会有两个选项,一个是GIST类型,一个是GIN类型,官网给出的参考如下: There are substantial perform ...

  5. PostgreSQL的索引膨胀

    磨砺技术珠矶,践行数据之道,追求卓越价值 回到上一级页面:PostgreSQL内部结构与源代码研究索引页    回到顶级页面:PostgreSQL索引页 索引膨胀,主要是针对B-tree而言. 索引膨 ...

  6. PostgreSQL查看索引的使用情况

    查看某个表的索引使用情况 select relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch from pg_stat_user_i ...

  7. PostgreSQL 分区索引演进

    PostgreSQL 分区表,操作性相当便捷. 但只能在创建时决定是否为分区表,并决定分区条件字段,普通表创建后,不能在修改为分区表. Note:通过其他方法也可转化为分区表. 和其他数据库一样,分区 ...

  8. postgresql gin索引使用

    由于属于老项目,postgresql使用版本9.6,主要解决‘%name%"查询无法使用索引问题.pg_trgm模块提供函数和操作符测定字母,数字,文本基于三元模型匹配的相似性, 还有支持快 ...

  9. PostGreSQL不同索引类型(btree & hash)的性能问题

    在关系型数据库调优中,查询语句涉及到的索引类型是不得不考虑的一个问题.不同的类型的索引可能会适用不同类型的业务场景.这里我们所说的索引类型指的是访问方法(Access Method),至于从其他维度区 ...

  10. postgresql逻辑结构--索引(六)

    一.索引简介 二.索引分类 三.创建索引 四.修改索引 五.删除索引

随机推荐

  1. 自然语言交流系统 phxnet团队 创新实训 项目博客 (一)

    2D文字聊天界面大致预期实现文字输入.发送消息.接收消息.你可以通过点击按钮让机器人开启聊天模式或者学习模式.又或是进入3D语音聊天界面或者退出. 目背景 (1) 开发动机的形态 随着科技的进步与生活 ...

  2. Hibernate关系映射 一对一双向外键关联@OneToOne Annotation方式

    首先还是来构造一个实际应用的场景,比如实体类车辆(Car),它具有以下属性:Id,品牌(brand),车牌(lisencePlate):实体类车牌(LisencePlate),它具有以下属性:Id,号 ...

  3. CentOS 7修改MySQL 5.6字符集为UTF-8

    MySQL编码原因会导致数据库出现中文乱码 解决办法: 修改MySQL数据库字符编码为UTF-8,UTF-8包含全世界所有国家需要用到的字符,是国际编码. 具体操作: 1.进入MySQL控制台 mys ...

  4. CentOS 7在桌面添加快捷方式

    直接把 /usr/share/applications 对应的 xxx.desktop 文件复制到桌面就OK!比如要在桌面创建Google Chrome Browser的快捷方式,直接在找到 /usr ...

  5. 【转】Linux内核源码分析方法

    一.内核源码之我见 Linux内核代码的庞大令不少人“望而生畏”,也正因为如此,使得人们对Linux的了解仅处于泛泛的层次.如果想透析Linux,深入操作系统的本质,阅读内核源码是最有效的途径.我们都 ...

  6. 基于swoole扩展实现真正的PHP数据库连接池

    转自:  http://rango.swoole.com/archives/265 PHP的数据库连接池一直以来都是一个难题,很多从PHP语言转向Java的项目,大多数原因都是因为Java有更好的连接 ...

  7. [转] web_reg_save_param得到的数组的处理

    方法一: 函数(sprintf,web_reg_save_param),其中红色字体是本文档最重要的#include "web_api.h" Action(){int i,iloo ...

  8. mybatis由浅入深day01_ 4.11总结(parameterType_resultType_#{}和${}_selectOne和selectList_mybatis和hibernate本质区别和应用场景)

     4.11 总结 4.11.1 parameterType 在映射文件中通过parameterType指定输入参数的类型.mybatis通过ognl从输入对象中获取参数值拼接在sql中. 4.11.2 ...

  9. Android DOM解析XML示例程序

    DOM方式解析xml是先把xml文档都读到内存中,然后再用DOM API来访问树形结构,并获取数据的.DOM比较符合人的思维模式,但是其对内存的消耗比较大. activity_main.xml < ...

  10. nohub和重定向文件

    1.如果使用远程连接的Linux的方式并想后台运行执行如下命令: 格式:nohup <程序名> & 比如:nohup /usr/local/collection/bin/start ...