说道GITS 索引，估计大部分熟悉 MYSQL , SQL SERVER , ORACLE 的客户都不大清楚这个索引又什么用，其他数据库已经通过 B TREE 的方式的索引，或HASH, BITMAP 等方式的来处理复杂的查询，GITS 索引能为我们带来什么。
那我们的话题的从一个表设计开始，例如
例如我们有一个学生考试，填写 A B C D 的项目，当然例如客户调查，或者之类的工作，在早期，设计这个表一般需要，类似下面的设计，需要为每个选项建立一个字段，并且用户在其中填写值
最后的统计方案也是，见图我们按照每个TAG 应该输入，同时对数据进行查找，尴尬的地方，我们要查询 输入 A B 的选择项的条目，必须写一个复杂的查询，并且如此即使有索引也是很难使用的。
所以传统数据库对这样的需求，处理起来不是很方便。
那POSTGRESQL 的 GtiS 是否可以改变这样的表设计方式，并且让查询的速度更快。
答案是OK的，其实之前已经讲过，但并未从表设计的角度来看，关于投票，选择，多选，单选，甚至简答题 等待都可以用这样的方法处理。
我们看一下表设计，其实就是两列，能可以顶上面的设计的多列。但传统的数据库查询这样的TAG 也是很困难的，所以才有了上面的设计。
我们可以直接现在当前的 库进行 gist 的扩展
create extension btree_gist;
然后才可以进行创建 gist 索引
create index gits_index on gtis_table using gist(tag);
然后我们直接查，任何的搜索组合都是可以走索引的。我们可以通过下面的查询计划直接查看基本都走索引了。
所以， 通过简化表设计后，基本的功能都会有，但开发的速度和查询的速度并不会因为表的设计简化后，变得不可接受，反而更容易操作。这或许就是POSTGRESQL 迷人的地方， 怪不得 Micorsoft 收购了 POSTGRESQL 的初创团队，这比买卖值得期待。
