tombo2-progress’s diary

できるだけ毎日１時間を切り取ってここに晒す。誤字脱字気にしない。日本語が崩壊するのも気にしない。最終的にまとめて本ブログに書く

Re: [WIP] Effective storage of duplicates in B-tree index. のメーリスを眺めてみた

https://www.postgresql.org/message-id/flat/56AB6D30.2040900%40postgrespro.ru#80cf7838f6285d5eb71475ac606fa5a7 からパフォーマンス影響に関してどれくらい言及されるたのかを中心に眺めてみた

メモそのままです(番号に意味はない)

感想

  • ここに出てくる内容だと、keyの重複が多いとindex sizeを30%~50%削減できるので、パフォーマンスの懸念はほとんどなさそう
  • この機能の提案者、他メンバーが pgbench, TPC-H, TPC-Eのデータで検証していた。
  • "Mouse genome informatics" (http://www.informatics.jax.org/software.shtml)での検証もしていてやはり分析用途で使われているんだなと再認識した
  • 変更に対する指定のベンチマークセットはなさそう。(Mailing listで言及がないだけで別のところで議論されてる可能性はある)

1. 最初の投稿(提案)

Anastasia Lubennikova 2015-08-31 07:41:15

B-tree index中の重複したキーの効率的な格納

Btreeの実装を変更することに対する確認事項

(内容は省略) 1. Compatibility. 2. There are several tricks to handle non-unique keys in B-tree. 3. Microvacuum.

2

Tomas Vondra 2015-08-31 15:26:53

  • 概ね賛成
  • GINと posting listsを実装したbtreeはどう違うのか？
  • posting listsを導入することのhigh concurrencyに対する影響は？

3, 2に対する返信

Anastasia Lubennikova 2015-09-01 09:31:54

  • UNIQUE feature以外の違いについて説明The difference between btree_gin and btree is not only UNIQUE feature. あたり
  • concurrencyの向上はそれほどないと思う

4

Tomas Vondra 2015-09-01 15:41:43

  • ok

5

Peter Geoghegan 2015-09-01 18:23:44

I'm glad someone is thinking about this, because it is certainly needed.

... 他いくつか意見 ...

6

Anastasia Lubennikova 2016-01-28 14:06:57

進捗報告

  • 特別な修正なしに広報互換性は保てそう
  • 各種indexで作成されるindexサイズ比較の結果を載せてる
i - number of distinct values in the index. So i=1 means that all rows
have the same key, and i=10000000 means that all keys are different.
The other columns contain the index size (MB).

i   B-tree Old  B-tree New  GIN
1   214,234375  87,7109375  10,2109375
10  214,234375  87,7109375  10,71875
100     214,234375  87,4375     15,640625
1000    214,234375  86,2578125  31,296875
10000   214,234375  78,421875   104,3046875
100000  214,234375  65,359375   49,078125
1000000     214,234375  90,140625   106,8203125
10000000    214,234375  214,234375  534,0625

今後追加実施予定の機能について

  1. Add storage_parameter 'enable_compression' for btree access method which specifies whether the index handles duplicates. default is 'off'
  2. Bring back microvacuum functionality for compressed indexes.
  3. Improve insertion speed. Insertions became significantly slower with compressed btree, which is obviously not what we do want.
  4. Clean the code and comments, add related documentation.

7

Thom Brown 2016-01-28 17:03:02

pgbenchでパフォーマンス検証した報告

Timing
Scale: master / patch
100: 10657ms / 13555ms (rechecked and got 9745ms)
500: 56909ms / 56985ms

Size
Scale: master / patch
100: 214MB / 87MB (40.7%)
500: 1071MB / 437MB (40.8%)

No performance issues from what I can tell.

8

Peter Geoghegan 2016-01-28 17:09:36

  • I/O boundの負荷かければ結構ちがうはずだよ

9

Thom Brown 2016-01-28 20:32:38

  • 300MBくらいのデータリストアしたらエラー出た

...

10

Anastasia Lubennikova Date: 2016-03-18 17:19:37

  • WAL機能もつけて進捗報告

... 次のバージョンで入れることが可能かの議論 ...

11

Anastasia Lubennikova Date: 2019-07-04 12:06:38

  • 進捗報告
  • reviewとtestを受けられそう
  • (新旧Btreeでのサイズ比較のグラフがわかりやすい)

12

Anastasia Lubennikova Date: 2019-07-04 17:38:21

  • "Mouse genome informatics" databaseのデータを入れたらたいてい50%くらい小さくなった

13

Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> Date: 2019-07-05 00:06:09

  • TPC-Hのデータで検証したらindex sizeが1/3くらいにできた

14

Rafia Sabih Date: 2019-07-31 14:59:22

  • TPC-Eのi_t_st_id indexは50%小さくなった