BRIN 是一种新的索引扫描方式， 它可以加速扫描非常大的表，而没有必要像B-Tree等其他传统索引的维护开销。
它的工作方式是维护数据库范围的 "summary" 数据

位图扫描的工作机制是通过读取每一个 summary 元组和拿该元组与查询条件比较； 如果查询条件的值在summary中，
在有损耗的TID位图中，范围内的全部的页都将会返回。否则不会返回。传统的索引扫描并不会采用这种方式，因为其
根本不会去存储 TID。
一个新的记录插入到表中， BRIN索引会更新summary的信息（如果插入的记录在已经包含的数据块中， 那么这个元组
信息将会被统计在内）否则不会更新。在最后一种情况， 使用 VACUUM 或者 brin_summarize_new_values() 函数将会
创建 summary 信息。
对于具有1维排序顺序类型的数据， summary 信息会包含每个字段的最大值和最小值在page范围内， 这种类型符号的操
作称之为 "MinMax", B-tree opclass 支持多种数据类型。 由于 BRIN的普遍性， 它也适合诸如数组， 集合类型， 范围类型
； 甚至是 枚举类型， 我们也可以去考虑实现特殊的minmax 操作。

catalog 可能出现一些变化，将会有更多令人兴奋的功能实现， 向美好的方向前进。

感谢
Simon Riggs, Alvaro Herrera Heikki Linnakangas

下面的实验主要考虑一下内容

1. 构建索引的时间花费
2. 更新索引的时间花费
3. 索引的大小
4. 查询走索引的访问时间和 = 操作的时间
5. 查询使用索引的访问时间和 between 操作的时间

实验准备
创建两个测试表

$ create table for_btree (id int8, payload text);

$ insert into for_btree (id, payload) select i, repeat('depesz', 100) from generate_series(1, 1000000) i;

$ create table for_brin (id int8, payload text);

$ insert into for_brin(id, payload) select i, repeat ('depesz', 100) from generate_series(1,1000000) i;

上述两个表的大小都是 650MB，

创建索引耗时对比实验

$ create index for_btree_id_idx on for_btree using btree (id);

$ create index for_brin_id_idx for_brin using brin (id);

更新索引的耗时对比实验

$ update for_btree set id = 1000000 + id where id < 300000;

$ update for_brin set id = 1000000 + id where id < 300000;

查看索引大小

$ /di+

查询耗时对比实验

1. = 操作的耗时对比

$ select count(*) from for_btree where id = 654321::int8;

$ select count(*) from for_brin where id = 654321::int8;

$ select count(*) from for_btree where id between 600000::int8 and 650000::int8;

$ select count(*) from for_brin where id between 600000::int8 and 650000::int8;

从上述实验可以看出， 对于 = 操作也好， 还是 between and 操作也好， BRIN 索引的耗时都要比 BTREE 索引耗时多很多。

补充信息， BRIN 索引是可以配置的。 我们可以从下面这张表中中得出具体的配置。具体的实现是通过修改参数 pages_per_range
的存储参数来实现的。 值越小， 指数越大。 并可能执行更快，但是更新的耗时也随之增加

pages_per_range index size create time update time search (=) time search (between) time
10000 24 kB 369.234 ms 8567.034 ms 87.606 ms 154.182 ms
1000 24 kB 373.150 ms 8812.391 ms 96.339 ms 133.546 ms
100 40 kB 360.555 ms 8867.043 ms 98.941 ms 131.126 ms
10 296 kB 392.038 ms 8619.480 ms 99.834 ms 132.327 ms
1 2800 kB 629.255 ms 8600.095 ms 114.882 ms 147.765 ms

来源： https://www.depesz.com/2014/11/22/waiting-for-9-5-brin-block-range-indexes/
这里的问题是，该索引为何没有加快索引（搜索）的速度， 可能和数据的分布有很大关系。但是总的来说， 它使用了很小的索引
存储开销， 加快了一些查询。这还是很不错的。

https://www.depesz.com/2014/11/22/waiting-for-9-5-brin-block-range-indexes/