PostgreSQL 10.0 preview 性能增强 - hash index metapage cache、高并发增强

postgresql , 10.0 , hash index

hash index是postgresql中一个非常老的索引访问方法，也是非常经典的索引。

hash index中存储的是索引字段的hash value，而不是原始值，btree索引中存储的是原始值。

因此，当字段非常大时，btree索引可能无法使用。

例如

这种情况下可以使用hash index，而正因为 hashindex中存储 的是哈希，所以它只能用作等值查询。

除非有一种哈希函数能保证哈希后的值和哈希前的值顺序具备一致性。否则hash index是无法支持排序、>,<,>=,<=的查询的。

哈希索引包含4种页，meta page, primary bucket page, overflow page, bitmap page.

metapage（0号页） , 包含了hash索引的控制信息，指导如何找到其他页面（每个bucket的primary page），以及当前存储概貌。其他索引的0号页基本都是这一个套路。

primary bucket page，hash index将存储划分为多个bucket（逻辑概念），每个bucket中包含若干page（每个bucket的page数量不需要一致），当插入数据时，根据计算得到的哈希，通过映射算法，映射到某个bucket，也就是说数据首先知道应该插入哪个bucket中，然后插入bucket中的primary page，如果primary page空间不足时，会扩展overflow page，数据写入overflow page.

在page中，数据是有序存储（tree），page内支持二分查找(binary search)，而page与page之间是不保证顺序的，所以hash index不支持order by。

overflow page，是bucket里面的页，当primary page没有足够空间时，扩展的块称为overflow page.

bimap page，记录primary , overflow page是否为空可以被重用。

注意bucket, page都没有提供收缩功能，即无法从os中收缩空间，但是提供了reuse(通过bitmap page跟踪）.

1. cache hash index meta page

缓存hash index meta page页到backend process的私有内存中，减少meta page的访问。

2. concurrent hash indexes

大幅提升查询性能，超过btree接近一倍。

这个patch的讨论，详见邮件组，本文末尾url。

postgresql社区的作风非常严谨，一个patch可能在邮件组中讨论几个月甚至几年，根据大家的意见反复的修正，patch合并到master已经非常成熟，所以postgresql的稳定性也是远近闻名的。

<a href="https://commitfest.postgresql.org/13/715/">https://commitfest.postgresql.org/13/715/</a>

<a href="https://www.postgresql.org/message-id/flat/[e-mail]#[e-mail]">https://www.postgresql.org/message-id/flat/[e-mail]#[e-mail]</a>

<a href="https://commitfest.postgresql.org/10/647/">https://commitfest.postgresql.org/10/647/</a>

<a href="https://www.postgresql.org/message-id/flat/[e-mail]#[e-mail]">https://www.postgresql.org/message-id/flat/[e-mail]#[e-mail]</a>

src/backend/access/hash/readme