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. [android] AndroidManifest.xml 详解

    第1部分 标签库+包路径+版本控制 <manifest xmlns:android="http://schemas.android.com/apk/res/android" ...

  2. js 延时

    alert(1);setTimeout(function(){alert(2);}, 1000);setTimeout(function(){alert(3);}, 2000);

  3. 关于Cocos2d-x中物理世界的物体乱跳的问题的解决

    这是电脑短时间内帧率低,无法满足游戏配置的帧率引起的. 解决方法: 第一种: 1.打开AppDelegate.cpp文件 2.把director->setAnimationInterval(1. ...

  4. Incentivizing exploration in reinforcement learning with deep predictive models

    Stadie, Bradly C., Sergey Levine, and Pieter Abbeel. "Incentivizing exploration in reinforcemen ...

  5. Android学习CursorWrapper与Decorator模式 (转至http://www.cnblogs.com/bastard/archive/2012/05/31/2527944.html)

    一 Decorator模式 意图: 动态的给一个对象添加一些额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活. 动态的给一个对象,而不是对整个类添加额外职责,说明此模式将采用的结 ...

  6. Asp.Net之后台载入JS和CSS

    在Asp.Net开发时,用到的JS库.通用的CSS等,在很多页面都会用到,而每次都须要手动引入.相当麻烦.并且有时一旦忘了引用,还得找半天才干找到问题.那有没有什么办法可以一劳永逸的呢?答案是有的. ...

  7. jquery validate自定义规则

    //检查身份证号码是否存在 $.validator.addMethod("checkIDCardExist", function (value, element) { if ($( ...

  8. postman从入门到精通

    今天总监让我给测试同事们培训postman,使用过postman的朋友应该知道,这个简直就是前后端接口调试神器.根据平时的经验以及自己到网上看了相关的帖子,对于postman又有了新的认识. post ...

  9. 解决 SharePoint 2010 拒绝访问爬网内容源错误的小技巧(禁用环回请求的两种方式)

    这里有一条解决在SharePoint 2010搜索爬网时遇到的“拒绝访问错误”的小技巧. 首先要检查默认内容访问帐户是否具有相应的访问权限,或者添加一条相应的爬网规则.如果目标资源库是一个ShareP ...

  10. 【Deeplearning】关注书目

    Deep Learning: A Practitioner's Approach http://www.amazon.com/Deep-Learning-Practitioners-Adam-Gibs ...