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