这样做的后果，比上面两种方法还要严重，因为 PostgreSQL 的查询规划器（query planner）不会将这个布尔表达式当作过滤条件。也就是说，规划器不会把它当作 WHERE 语句：
WHERE (data->>'type') = 'submit' AND (data->>'path') = '/signup/'
所以，我们索引的字段：
((data->>'type') = 'submit' AND (data->>'path') = '/signup/')
的值始终为 true。 当我们用这个索引当作条件过滤事件的时候，不管表达式的结果是 true 还是 false，都会先把事件数据读出来，加载完后，再过滤。
这么一来, 索引的时候会从磁盘中读取许多不必要的数据, 此外也要检查每一行数据的有效性. 拿我们例子中的数据集来说, 这样的查询第一次要 25 秒, 之后会降到 8 秒. 这样的结果比索引整个时间字段还要差一些.
局部索引能在很大程度上, 提高那些通过断言过滤出表中一部分数据的查询的速度. 对于以流量论英雄(Judging by traffic )的 #postgresql IRC 来说, 局部索引显得有些资源利用不足. 对比全索引, 局部索引有适用范围更广的断言(greater range of predicates), 配合高选择性过滤条件(highly selective filters), 写操作和磁盘空间会变得更少. 要是你经常查询某个表中的一小部分数据, 应当优先考虑局部索引.
是不是开始爱上 PostgreSQL 了? 要了解它的各种功能和特点, 请移步到这里 @danlovesproofs.
想不想将强大的技术变得更易于使用? 有兴趣就给我们发邮件 jobs@heapanalytics.com.
[1] 这种问题可以通过对表分区来解决. 把表中有价数据(high-value events)和其他数据分开放在不同的子表中. 不过, 如果有价值数据的种类比较多, 这种方法就不适用, 因为, 每次添加一个新的有价值数据的种类, 都要重新对表分区.
[2] 通过 heap-only tuples 优化, 可以大大的降低更新操作的开销, 但是, 每次 INSERT 或 DELETE 操作依然需要更新3个索引.
[3] 我们可以通过建一个 '多列索引' 对 3 个字段同时索引. 如: on((data->>'type'), (data->>'path'), time). 这个索引占 755 mb 磁盘空间, 比建 3 个索引用的磁盘空间也就少了 26%, 而且其他问题依然存在. 此外, 这样的索引可能对同样数据的其他查询, 没什么用处. 所以, 如果我们有几种不同的类型的有价值数据, 节省磁盘空间这点优势也就不存在了.
[4] 相关的查询规划(The relevant query plan):
------------------------------------华丽丽的分割线------------------------------------
CentOS 6.3环境下yum安装PostgreSQL 9.3
Ubuntu下LAPP（Linux+Apache+PostgreSQL+PHP)环境的配置与安装
PostgreSQL配置Streaming Replication集群
如何在CentOS 7/6.5/6.4 下安装PostgreSQL 9.3 与 phpPgAdmin
------------------------------------华丽丽的分割线------------------------------------