PostgreSQLエンタープライズ・コンソーシアム 技術部会 WG#1

2018年度WG1活動報告書

PostgreSQL Enterprise Consortium

目次
目次
1. 改訂履歴
2. ライセンス3. はじめに3.1. PostgreSQLエンタープライズコンソーシアムとWG1について
3.1.1. 各WGとWG1の活動テーマ
3.2. WG1の活動テーマ
3.3. 本資料の概要と目的
3.3.1. 2018年度の活動テーマ
3.3.2. 定点観測（スケールアップ）
3.3.3. Windows版PostgreSQL性能
3.3.4. JITコンパイル
3.3.5. パラレルクエリ
3.4. 成果の公開
3.4.1. 2017年度までの活動テーマの紹介
3.5. 実施体制
3.6. 実施スケジュール
3.7. 謝辞
4. 定点観測(スケールアップ検証)
4.1. 検証概要
4.2. pgbench とは
4.3. 検証構成
4.3.1. ハードウェア構成
4.3.2. ソフトウェア構成
4.3.3. カーネル設定
4.3.4. PostgreSQL 設定
4.3.5. 環境
4.4. 検証方法(参照系)
4.5. 検証結果(参照系)
4.6. 追加検証(参照系)
4.7. 検証方法(更新系)
4.8. 検証結果(更新系)
4.9. 追加検証(更新系)
4.10. 2017年度検証の残課題
4.11. まとめ
5. Windows版PostgreSQL性能検証
5.1. 検証概要
5.2. 検証構成
5.2.1. ハードウェア構成
5.2.2. ソフトウェア構成
5.3. 検証モデル
5.3.1. データベースクラスタ構成
5.3.2. 検証用ベンチマーク
5.3.2.1. 初期データ登録
5.3.3. 仮測定
5.3.3.1. 参照系仮測定
5.3.3.2. 更新系仮測定5.3.3.3. バグレポート
5.3.4. 本測定
5.3.5. PostgreSQL 設定
5.3.6. OSリソース情報の収集
5.4. 検証結果
5.4.1. 参照系
5.4.2. 更新系
5.5. まとめ
6. JITコンパイル 性能検証
6.1. 検証概要
Page 2 of 67

2
6
7
8
8
8
8
8
8
9
9
9
9
9
9
9
10
10
11
11
11
12
12
13
13
13
14
14
15
15
17
18
18
19
21
22
22
22
22
22
23
23
23
23
23
23
24
24
24
25
25
25
25
26
27
28
28

PostgreSQL Enterprise Consortium

6.2. JITコンパイルとは
6.2.1. JITコンパイル
6.2.2. PostgreSQLでのJITコンパイル
6.2.3. JITコンパイルに関するパラメータ
6.3. 検証構成
6.3.1. 検証ハードウェア環境
6.3.2. 検証ソフトウェア環境
6.4. 検証方法
6.4.1. 検証項目
6.4.1.1. 検証1
6.4.1.2. 検証2
6.4.1.3. 検証3
6.4.2. データモデル
6.4.3. DB設定
6.4.4. 測定手順
6.4.4.1. 検証1測定方法
6.4.4.2. 検証2測定方法
6.4.4.3. 検証3測定方法
6.4.4.3.1. No.1
6.4.4.3.2. No.2
6.4.4.3.3. No.3
6.4.4.3.4. No.4
6.5. 検証結果
6.5.1. 検証1
6.5.2. 検証2
6.5.3. 検証3
6.6. 考察6.6.1. 検証1
6.6.1.1. 乗算を含むクエリ
6.6.1.2. sum関数を含むクエリ
6.6.2. 検証2
6.6.3. 検証3
6.6.3.1. No.1-1
6.6.3.2. No.2-2
6.6.3.3. 削減率が低い原因の考察
6.7. まとめ

28
28
28
29
29
29
29
29
29
29
30
30
30
32
32
32
33
33
33
34
35
36
37
37
38
39
39
39
40
40
40
41
41
42
43
44
46
46
46
46
46
46
47
48
48
49
49
49
49
49
49
49
49
50
50
50
50
50
51

7. パラレルクエリ 性能検証
7.1. 検証概要
7.1.1. Star Schema Benchmarkとは
7.2. パラレルクエリとは
7.2.1. パラレルクエリ
7.2.2. PostgreSQLでのパラレルクエリ
7.2.3. パラレルクエリに関連するパラメータ
7.3. 検証構成
7.3.1. 検証ハードウェア構成
7.3.2. 検証ソフトウェア構成
7.4. 検証方法
7.4.1. 検証項目
7.4.1.1. 検証A
7.4.1.2. 検証B
7.4.1.3. 検証C
7.4.1.4. 対照群
7.4.2. データモデル
7.4.3. 使用クエリについて
7.4.4. DB設定
7.4.5. 測定手順
7.4.5.1. 検証A測定方法
7.4.5.2. 検証B測定方法
7.4.5.3. 検証C測定方法
Page 3 of 67

PostgreSQL Enterprise Consortium

7.5. 検証結果
7.5.1. 検証A(パラレルクエリを有効にしたことによる効果)
7.5.2. 検証B(並列処理数(起動するワーカーの数)の違いによる検証結果)
7.5.3. 検証C
7.5.4. 対照群(パラレルクエリoff)
7.6. 考察7.6.1. 検証A
7.6.2. 検証B
7.6.2.1. max_worker_processes、max_parallel_workers、max_parallel_workers_per_gather 間の関係
7.6.2.2. バージョン11における SSB q4.3 の性能
7.6.3. 検証C
7.7. 総括
7.8. Appendix 2016年度検証モデルでの結果
8. おわりに
9. 著者
10. Appendix 検証環境

Page 4 of 67

51
51
53
57
57
59
59
59
59
59
61
62
62
65
66
67

PostgreSQL Enterprise Consortium

Page 5 of 67

PostgreSQL Enterprise Consortium

1. 改訂履歴
版

1.0

改訂日

変更内容

2019/03/29 新規作成
定点観測(スケールアップ検証)、及びW in do w s 検証を公開

1.1

2019/04/05 JITコンパイル検証、及びパラレルクエリ検証を公開

1.2

2019/11/26 EDB 版インストーラ問題に関するEDB 社の調査結果を追記

Page 6 of 67

PostgreSQL Enterprise Consortium

2. ライセンス
本作品はCC-B Yライセンスによって許諾されています。 ライセンスの内容を知りたい方は こちら でご確認ください。 文書の内容、表記に関する誤り、ご要望、感想等につきましては、PG ECo n s のサイト を通じてお寄せいただきますようお願いいたします。

Eclip se は、Eclip se Fo u n datio n In c の米国、およびその他の国における商標もしくは登録商標です。
IB M およびDB 2 は、世界の多くの国で登録された In tern atio n al B u sin ess Mach in es Co rp o ratio n の商標です。
In tel 、インテルおよびXeo n は、米国およびその他の国における In tel Co rp o ratio n の商標です。
Java は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Lin u x は、Lin u s To rvalds 氏の日本およびその他の国における登録商標または商標です。
Red Hat およびSh ado w man lo go は、米国およびその他の国におけるRed Hat,In c. の商標または登録商標です。
Micro so ft 、W in do w s Server 、SQL Server 、米国 Micro so ft Co rp o ratio n の米国及びその他の国における登録商標または商標です。
MySQL は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
O racle は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Po stgreSQL は、Po stgreSQL Co mmu n ity Asso ciatio n o f Can ada のカナダにおける登録商標およびその他の国における商標です。
W in do w s は米国 Micro so ft Co rp o ratio n の米国およびその他の国における登録商標です。
TPC, TPC B en ch mark, TPC-B , TPC-C, TPC-E, tp mC, TPC-H, TPC-DS, Qp h H は米国Tran sactio n Pro cessin g Perfo rman ce Co u n cil の商標です。
その他、本資料に記載されている社名及び商品名はそれぞれ各社が 商標または登録商標として使用している場合があります 。

Page 7 of 67

PostgreSQL Enterprise Consortium

3. はじめに3.1. PostgreSQLエンタープライズコンソーシアムとWG1について
Po stgreSQL エンタープライズコンソーシアム(略称 PG ECo n s) は、Po stgreSQL 本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPo stgreSQL の普及を推進することを目的として、2012 年4 月に設立された団体です。

3.1.1. 各 WGと WG1の 活動テー マ
PG ECo n s 技術部会ではPo stgreSQL の普及を促進する技術的な課題の解決をテーマとし、「大規模基幹業務に向けた Po stgreSQL の適用領域の明確化」を大きな目標に活動しております(2012 年7 月6 日開催のPG ECo n s セミナーより)。
この目標に向けて技術部会では課題を以下の課題領域に分類し、三つのワーキング・グループ(W G )で分担することとしました。

表 3.1 PG ECo n s における課題領域
課題領域

概要

担当 WG

性能

性能評価手法、性能向上手法、チューニングなど

1

互換性

データ、スキーマ、SQL 、ストアドプロシージャの互換性

2

可用性

高可用クラスタ、B CP

3

保守性

保守サポート、トレーサビリティ

3

運用性

監視運用、バックアップ運用

3

セキュリ
ティ

監査

3

接続性

他ソフトウェアとの連携

3

W G 1 （新技術検証ワーキンググループ）
新しい技術の実検証から有用性や課題を検討
Po stgreSQL の最新バージョンの性能傾向の調査・検討
W G 2 （移行ワーキンググループ）
利用者観点で整備した「移行フレームワーク」に基づき、成果物のユーザビリティ向上、 内容の最新化などを実施
W G 3 （課題検討ワーキンググループ）
データベース管理者やアプリケーション開発者が抱える、現場の課題に向けた課題に対するテーマを設定

3.2. WG1の活動テーマ
W G 1 では、Po stgreSQL の新技術に対する技術検証、および新バージョンにおける性能検証を進めるにあたり、以下のような観点から個々の検証テーマをたてて、参加企業が集まってチームを作って具体的な検討を進めています。

表 3.2 W G 1 の検証テーマ
検証観点

具体的なテーマの例

新機能の技術検証

文字列データやJSO N などの特定データ型に対する処理性能や利便性、VACU U M に代表される保守コマンドの改善など性能向上機能定点観測

パラレルクエリ、パーティショニング、クエリキャッシュ、高速ロードなど
最新バージョンの Po stgreSQL に対して、前バージョンとの性能傾向の差異を把握する

スケ ールアップ

マルチコアCPU でのスケールアップ性検証。定点観測で実施する

スケ ールアウト

負荷分散クラスタでのスケールアウト性検証

性能検証手法オンラインやバッチなどの業務別性能モデル、サイジング手法

性能チ ューニング

チューニングノウハウの整備、実行計画の制御手法

3.3. 本資料の概要と目的
本資料は、2018 年10 月にリリースされた Po stgreSQL 11 のスケール性、新技術・機能向上、W in do w s 版Po stgreSQL 性能、および近年のPo stgreSQL に関連する技術について調査と性能検証を実施し、その方法と結果を報告します。

3.3.1. 2018年度の 活動テー マ

Page 8 of 67

PostgreSQL Enterprise Consortium

2018 年度は、2018 年10 月18 日にリリースされた Po stgreSQL 11 を対象として以下のようなテーマで検証を実施しました。
定点観測（スケールアップ）
W in do w s 版Po stgreSQL 性能
JITコンパイル
パラレルクエリ以下、各検証テーマごとの概要を紹介します。

3.3.2. 定点観測（ スケー ル アッ プ）
例年通り、Po stgreSQL 新旧バージョンにおけるスケール性能を比較する検証を行いました。 参照系クエリの性能は 10 と 11 で差は見られませんでした。しかし、同検証で副次的に集約計算性能の向上を観察することができました。 更新系クエリの性能は 11 で性能向上が見られました。これは clo g に関する処理の変更が主な原因でした。 また、昨年度発覚した 10 の更新系クエリの性能低下について再検証したところ、推測していた通りセマフォの変更が原因であることが確認できました。

3.3.3. Windows版 PostgreSQL 性能
昨年に引き続き、Lin u x 上で実施していた定点観測と同様の測定をW in do w s 版Po stgreSQL でも実施し、Lin u x 版Po stgreSQL と、W in do w s 版Po stgreSQL の性能の傾向を評価しました。 同一スペックのサーバ上でLin u x/W in do w s のO S の差異による測定を実施した結果、参照系はCPU 数を超えない範囲の同時接続数、つまり過負荷状態でなければ、W in do w s 版Po stgreSQL は性能面ではLin u x 版と遜色はないと考えられます。 更新系は、同時接続数が32 を超える場合に、Lin u x 版と比較して W in do w s 版のtp s が大きく劣るという結果となりました。

3.3.4. JIT コン パイル
Po stgreSQL11 で追加された JITコンパイルについて、有効なクエリ種の調査と実行時間の削減効果の検証を行いました。 四則演算と集約関数を含むクエリに有効であることがわかりました。 また、カラムのデータ型の違いによっても削減効果の違いがあることがわかりました。 O LAP 系の大規模なクエリを実行した場合には、削減効果は見られたもののクエリの内容によって効果に差があることがわかりました。

3.3.5. パラレル クエリ
Po stgreSQL 9.6 にてメニーコアを有効活用するパラレルクエリが実装され、バージョン10 以降で継続的に強化されています。 今回は、B I のようなO LAP において使用される形式のクエリを模したベンチマークテストであるStar Sch ema B en ch mark で定義されているクエリを題材とし、O LAP においてバージョン9.5 〜11 で、パラレルクエリが実装されたことによりどのように性能が変化するのかを検証しました。 また、バージョン11 にて実装された、B -Tree インデックスのパラレル作成について、パラメータによって、どのよ
うに性能が変化するのかを検証しました。 検証の結果、テーブルサイズによって決定される並列度までは性能が向上しましたが、実行計画の変化に起因して性能が頭打ちになる場合があることがわかりました。 性能が頭打ちになる現象については、並列度を決定するロジックが不完全であることが原因とわかりました。

3.4. 成果の公開
本資料も含めて、活動成果は報告書の形にまとめて、 PG ECo n s のW eb サイト で公開しています。また、過去の活動成果も含めてテーマ毎に報告書を検索できるように
成果物総索引 も用意しています。

3.4.1. 2017年度まで の 活動テー マの 紹介
2012 年度は、企業システムで使われる機器構成で、Po stgreSQL のスケールアップ、スケールアウトによる性能特性、性能限界を検証しました。 企業システムへのPo stgreSQL 採用や、システム構成を検討するための、一つの指針として「 2012 年度W G 1 活動報告書」として情報を公開しています。
2013 年度は、2012 年度に引き続き2013 年9 月9 日にリリースされた Po stgreSQL 9.3 を対象としたスケールアップの定点観測を実施、Po stgreSQL 9.3 新機能による性能影響も合わせて評価することとしました。 また、更新スケールアウト構成が可能なPo stgres-XC の測定パターンを変えた再測定により、最適な利用指針を探る評価を実施することとしました。 さらに、2013 年度の新たな取り組みとしてデータベースの性能向上に着目、データベースのI/O 負荷分散機能であるパーティショニングや、ハード
ウェアを活用した性能向上の検証を実施しました。

2014 年度は、2013 年度に引き続き2014 年12 月7 日にリリースされた Po stgreSQL 9.4 を対象としたスケールアップの定点観測を実施、そして 9.4 新機能のW AL 改善を評価するために更新系処理を新たに評価することとしました。 また、新たな取り組みとして物理環境以外の環境におけるデータベースの性能評価に着目、KVM を使った仮想化環境と、Lin u x コンテナのDo cker 環境の検証を実施しました。
2015 年度は、2016 年1 月7 日にリリースされた Po stgreSQL 9.5 を対象とした、スケールアップの定点観測を実施しました。 これは昨年度に引き続き、参照系・更新系の双方で性能を調査するものです。 Po stgreSQL 9.5 での2 つの新機能、B RIN インデックスとParallel Vacu u m について、その利用ノウハウが得られるような検証を行いました。最後に、基盤となるLin u x O S の主要なディストリビューションの一つであるRed Hat En terp rise Lin u x 6 と7 とでPo stgreSQL の性能を比較しました。
2016 年度は、2016 年9 月にリリースされた Po stgreSQL 9.6 を対象とした、スケールアップの定点観測を実施しました。 これは例年通り、参照系・更新系の双方で性能を調査するものです。 Po stgreSQL 9.6 の新機能のパラレルクエリや改善が行われた VACU U M について効果を検証しました。 また、Pgp o o l-II のスケールアウト性能、
JSO N/JSO NB データ型に関する性能評価を行いました。
2017 年度は、2017 年10 月にリリースされた Po stgreSQL 10 を対象とした、スケールアップの定点観測を実施しました。 これは例年通り、参照系・更新系の双方で性能を調査するものです。 Po stgreSQL 10 で強化されたパラレルクエリの性能検証、新機能であるロジカルレプリケーションを利用した負荷分散の効果検証、同期・非同期レ
プリケーション構成や混在環境における性能検証、FDW 機能利用時の性能検証を行いました。

3.5. 実施体制
Page 9 of 67

PostgreSQL Enterprise Consortium

2018 年7 月19 日に開催された 2018 年度第1 回技術部会より、以下の体制で実施しています(企業名順)。
表 3.3 2018 年度W G 1 参加企業

SRA O SS, In c. 日本支社
NEC ソリューションイノベータ株式会社
NTTテクノクロス株式会社
日本電信電話株式会社
富士通株式会社
この中で、NEC ソリューションイノベータ株式会社は、「主査」として W G 1 の取りまとめ役を担当することになりました。

3.6. 実施スケジュール
2018 年度は、下記スケジュールで活動しました。
表 3.4 実施スケジュール
活動概要

スケ ジュール

W G 1 スタート

2018 年7 月19 日

実施計画策定2018 年7 月～12 月

検証実施2019 年1 月～2019 年2 月

2018 年度W G 1 活動報告書作成

2019 年2 月～2019 年3 月

総会と成果報告会

2019 年4 月25 日(東京)、2019 年5 月10 日(大阪/報告会のみ実施)

3.7. 謝辞
検証用の機器を日本ヒューレット・パッカード株式会社、および富士通株式会社(敬称略)よりご提供いただきました。 この場を借りて厚く御礼を申し上げます。

Page 10 of 67

PostgreSQL Enterprise Consortium

4. 定点観測 (スケールアップ検証 )4.1. 検証概要
W G 1 では、Po stgreSQL の新バージョン・新リリースにあわせて、新旧バージョンの性能比較やスケールアップ特性の検証を主な目的にした定点観測を2012 年度から実施
してきました。2014 年度からは、それまでの参照処理に加えて更新処理についても検証を実施し、検証結果の公開を行うようになりました。2018 年度は32 コアのCPU （ Xeo n G o ld 6142 ）、メモリ384G B といったスペックのサーバで、最新のPo stgreSQL バージョン 11 と前バージョンの 10 との参照性能の比較および更新性能の比較を行いました。

4.2. pgbench とは
本検証では、 p gb en ch というベンチマークツールを使用しました。

p gb en ch はPo stgreSQL に付属する簡易なベンチマークツールです(バージョン9.5 より前はco n trib に付属)。標準ベンチマーク TPC-B （銀行口座、銀行支店、銀行窓口担当者などの業務をモデル化）を参考にしたシナリオに基づくベンチマークの実行のほか、検索クエリのみを実行するシナリオも搭載されています。また、カスタムスクリプトを用意することで、独自のシナリオでベンチマークを実行することも可能です。

p gb en ch でベンチマークを実行すると、以下のように 1 秒あたりで実行されたトラザクションの数(TPS: Tran sactio n s Per Seco n d)が出力されます。なお、「 in clu din g
co n n ectio n s estab lish in g 」はPo stgreSQL への接続に要した時間を含んだ TPS を、「 exclu din g co n n ectio n s estab lish in g 」はこれを含まないTPS を示します。

transaction type: <builtin: TPC-B (sort of)>scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
latency average = 4.433 ms
tps = 225.580586 (including connections establishing)tps = 241.413390 (excluding connections establishing)p gb en ch には「スケールファクタ」という概念があり、データベースの初期化モードでp gb en ch を起動することにより、任意のサイズのテスト用のテーブルを作成できます。デフォルトのスケールファクタは1 で、このとき「銀行口座」に対応する「 p gb en ch _acco u n ts 」というテーブルで10 万件のデータ、約15MB のデータベースが作成されます。
以下に、各スケールファクタに対応するデータベースサイズを示します。
表 4.1 スケールファクタに対するデータベースサイズ
スケ ールファク タ

データ ベースサイ ズ

1

15MB

10

150MB

100

1.5G B

1000

15G B

5000

75G B

初期化モードでは p gb en ch _acco u n ts の他にもテーブルが作成されます。作成されるテーブルのリストを以下に示します。
表 4.2 p gb en ch _acco u n ts(口座)
列名

データ 型

コ メ ントaid

in tegerアカウント番号(主キー)b id

in teger

支店番号

ab alan cein teger

口座の金額

fillerch aracter(84)

備考

Page 11 of 67

PostgreSQL Enterprise Consortium
表 4.3 p gb en ch _b ran ch es(支店)
列名

データ 型

コ メ ントb idin teger

支店番号b b alan cein teger

口座の金額

ch aracter(84) 備考
表 4.4 p gb en ch _tellers(窓口担当者)

filler

列名

データ 型

コ メ ントtid

in teger

担当者番号

b id

in teger

支店番号

tb alan cein teger

口座の金額

fillerch aracter(84) 備考

スケールファクタが 1 の時、p gb en ch _acco u n ts は 10 万件、p gb en ch _b ran ch es は 1 件、p gb en ch _tellers は 10 件のデータが作成されます。スケールファクタを増やすとこれに比例して各テーブルのデータが増えます。

p gb en ch には、様々なオプションがあります。詳細は Po stgreSQL 文書 をご覧ください。ここでは、本検証で使用している主なオプションのみを説明します。
表 4.5 ベンチマークテーブル初期化
オプショ ン

説明-i

ベンチマークテーブルの初期化-sスケールファクタ

-F

作成するテーブルのフィルファクタ
表 4.6 ベンチマークの実行
オプショ ン説明-c

同時接続クライアント数-jp gb en ch 内のワーカスレッド数-T

ベンチマークを実行する秒数-n

実行前にバキュームを行わない-P指定した秒数ごとのレポートを表示-r

実行クエリの平均レイテンシを表示

4.3. 検証構成
4.3.1. ハー ドウ ェア構成

Page 12 of 67

PostgreSQL Enterprise Consortium

図 4.1 検証ハードウェア構成
本検証では上図構成のうち「 DB サーバ#2 」と「負荷掛け用」を用いました。

4.3.2. ソフトウ ェア構成
検証環境のソフトウェア構成を示します。
表 4.7 DB サーバ#2

OS

Red Hat En terp rise Lin u x 7.5

Po stgreSQL

10.6, 11.1
表 4.8 負荷掛け用

OS

Red Hat En terp rise Lin u x 7.5

p gb en ch

11.1

4.3.3. カー ネ ル 設定
O S デフォルト
ハイパースレッディングは利用しない

4.3.4. PostgreSQL 設定
Po stgreSQL 設定ファイル p o stgresql.co n f での設定は以下の通りです。これらは参照系検証と更新系検証で共通です。
Page 13 of 67

PostgreSQL Enterprise Consortium

listen_addresses = '*' ... 負荷掛け用マシンからの接続用
max_connections = 500 ... 多めに設定
shared_buffers = 40GB
work_mem = 1GB
maitenance_work_mem = 20GB
checkpoint_timeout = 60min
max_wal_size = 160GB

4.3.5. 環境
以下の手順で、データベースクラスタを作成しました。

in itdb でデータディレクトリを作成し、上記に示した設定をp o stgresql.co n f に記述します。

$ initdb --no-locale --encoding=utf-8$ vi $PGDATA/postgresql.conf

Po stgreSQL を起動してベンチマーク用のデータベースを作成します。

$ pg_ctl start$ createdb [dbname]ここからは、参照系性能と更新系性能についてそれぞれ検証していきます。

4.4. 検証方法(参照系)
p gb en ch コマンドを用いて、ベンチマーク用データベースをスケールファクタ 2000 で初期化します。

$ pgbench -i -s 2000 [dbname]

本検証では p g_p rew arm モジュールを用います。

p g_p rew arm はバッファキャッシュにテーブルデータを読み込むためのモジュールで、バッファキャッシュがクリアされているデータベース起動直後の性能低下状態を解消するために用いることができます。
まず、測定スクリプト実行前に p g_p rew arm を実行します。これによりテーブルデータはすべてバッファキャッシュに格納されます。

=# SELECT pg_prewarm('pgbench_accounts');

以下のスクリプトを参照系カスタムスクリプトとして作成して、適度な負荷がかかるようにしました。これは、p gb en ch の標準 シナリオ（ p gb en ch -S ）ではCPU に充分な負荷がかからないためです。具体的には、ランダムに 10000 行を取得しています。

\set naccounts 100000 * :scale\set row_count 10000\set aid_max :naccounts - :row_count\setrandom aid 1 :aid_max
SELECT count(abalance) FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count;

これを、クライアント用検証機から

Page 14 of 67

PostgreSQL Enterprise Consortium$ pgbench -n -h [host] -p [port] -c [clients] -j [threads] -f [参照系カスタムスクリプト] -T 300 -s 2000 -P 1
-r [dbname]

として実行しました。SELECTのみであるためVACU U M を実行せず(-n )、p gb en ch クライアント数(-c)とスレッド数(-j)を変動させながら、300 秒ずつ (-T)実行しています。ス
レッド数はクライアント数の半分としています。スケールファクタ (-s)にはデータベース初期化時と同じ2000 を指定します。また、1 秒毎の進捗レポート取得(-P)と各クエリの平均レイテンシ(-r)も取得する指定にしました。（ただし、-P, -r の指定によって得られた結果は今回の考察に直接用いることはありませんでした）
計測はクライアント数ごとにそれぞれ3 回ずつ実行し、その中央値を結果とします。また、変動させるクライアント数は{1 4 16 32 48 64 80 96} です。

4.5. 検証結果(参照系)
検証結果のTPS のグラフを以下に示します。TPS は接続確立にかかった時間を無視した値(exclu din g co n n ectio n s estab lish in g)を用いています。(以降同様)

10, 11 はともにクライアント数増加につれて TPS が増加し、コア数を超えた辺りのクライアント数でTPS は頭打ちとなっています。11 のTPS は平均 5% ほど 10 を上回る結果となりました。

図 4.2 各クライアント数に対する TPS (参照系)
続いて、バージョン間の性能差異をもたらした原因を追求するため追加検証を行いました。

4.6. 追加検証(参照系)
上記の結果から 11 は 10 よりも参照系性能が向上したように見えますが、実は 11 の リリースノート には以下の記述があります。

Page 15 of 67

PostgreSQL Enterprise ConsortiumImp ro ve th e sp eed o f aggregate co mp u tatio n s (An dres Freu n d)
「集約計算の速度が改善されました。」
このため、例年利用している以下のクエリには集約関数の co u n t() が含まれているため、上記の性能向上は集約計算の性能向上のみによるものであった可能性があります。
そこで、検証に用いるクエリを、以下の集約計算を使用しないクエリに変更して 10, 11 のパフォーマンス比較を再度行いました。

SELECT abalance FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count offset:row_count limit 1;

結果は以下の通りです。

図 4.3 各クライアント数に対する TPS (参照系、集約計算無しクエリ)
さらに、集約計算を使用している元のクエリと集約計算を使用しない新しいクエリについてバージョン 10 から 11 に対しての性能向上率を比較したものが以下の通りです。

Page 16 of 67

PostgreSQL Enterprise Consortium

図 4.4 性能向上率比較 (agg: 集約計算有り, n o agg: 集約計算無し)
集約計算を含んだクエリは各クライアント数で平均 5% 程度の性能向上しているのに対して、集約計算無しクエリは全く性能向上していませんでした。これらの結果から、最初の検証クエリの性能向上は集約計算の箇所が大きく影響していたことが示唆されます。よって、バージョン 10, 11 間では一般的な参照性能の向上はありませんでした。また、副次的ではありますが本検証では集約計算(ここではco u n t())における性能向上を観察することができました。
続いて、更新性能について検証します。

4.7. 検証方法(更新系)
p gb en ch コマンドを用いて、ベンチマーク用データベースをスケールファクタ 2000 で初期化します。このとき、フィルファクタは 80 とします。

$ pgbench -i -s 2000 [dbname] -F 80

更新系検証でも、 p g_p rew arm モジュールを用います。測定スクリプト実行前に p g_p rew arm を実行します。これによりテーブルデータはすべてバッファキャッシュに格納されます。

=# SELECT pg_prewarm('pgbench_accounts');

以下のスクリプトを更新系カスタムスクリプトとして作成して、適度な負荷がかかるようにしました。

\set naccounts 100000 * :scale\set aid_val random(1, :naccounts)
UPDATE pgbench_accounts SET filler=repeat(md5(current_timestamp::text),2) WHERE aid = :aid_val;

これを、クライアント用検証機から

Page 17 of 67

PostgreSQL Enterprise Consortium$ pgbench -n -h [host] -p [port] -c [clients] -j [threads] -f [更新系カスタムスクリプト] -T 300 -s 2000 -P 1
-r [dbname]

として実行しました。VACU U M を実行せず(-n )、p gb en ch クライアント数(-c)とスレッド数(-j)を変動させながら、300 秒ずつ (-T)実行しています。スレッド数はクライアント数の半分としています。スケールファクタ (-s)にはデータベース初期化時と同じ2000 を指定します。また、1 秒毎の進捗レポート取得(-P)と各クエリの平均レイテンシ(-r)も取得す
る指定にしました。（ただし、-P, -r の指定によって得られた結果は今回の考察に直接用いることはありませんでした）
計測はクライアント数ごとにそれぞれ3 回ずつ実行し、その中央値を結果とします。また、変動させるクライアント数は{1 4 16 32 48 64 80 96} です。このとき、更新系検証の場合は実行後のテーブルを使い回さず、毎回初期化しています。

4.8. 検証結果(更新系)
検証結果のTPS のグラフを以下に示します。 10, 11 ともにクライアント数増加につれて TPS が増加しましたが、よりクライアント数が多いほど 11 のTPS が 10 のTPS を上回る結果となりました。96 クライアントに至っては 10% の向上が見られました。

図 4.5 各クライアント数に対する TPS (更新系)

11 の更新性能向上の原因を解明するために別途、追加の検証を行いました。

4.9. 追加検証(更新系)
さて、ここで 11 の リリースノート を参照すると、

Imp ro ve p erfo rman ce o f co mmittin g mu ltip le co n cu rren t tran sactio n s (Amit Kap ila)
Page 18 of 67

PostgreSQL Enterprise Consortium「同時実行トランザクションのコミットの性能が改善されました。」という記述があります。上記の記述にあたるソースコードコミットは [b aaf272ac] であり、このコミットでは clo g 更新処理をグループ化する実装が行われています。

clo g 更新処理のグループ化とはつまり、複数のトランザクションによりトランザクションステータスの更新処理が競合している際に単一のリーダープロセスが複数の更新処理をまとめて行い、トランザクションステータス更新時に発生する CLo gCo n tro lLo ck の回数を減らすための処理です。この処理自体の w ait_even t は
Clo gG ro u p U p date として表されます。
追加検証では [b aaf272ac] の実装が実際に性能に影響していたかどうかを確認します。そのために追加検証では [b aaf272ac] の実装箇所を実装前の状態に戻した
ビルドを用います。
「バージョン10 ビルド」、「バージョン11 ビルド」、「バージョン11 から [b aaf272ac]の実装を外したビルド」で性能比較した結果は以下の通りです。このとき、10 と 11 で性能差が一番大きかった 96 クライアントで比較しています。

図 4.6 clo g 更新のグループ化実装を外したビルドと比較（クライアント数 96 ）図の「 11reverted 」が「バージョン11 から [b aaf272ac]の実装を外したビルド」です。
以上の結果から、10% の性能向上のうち 5% 以上は [b aaf272ac] の修正が更新性能向上に寄与していることが確認できました。ただ残念ながら、残りの 5 ％ 未満の性能向上については検証期間の関係から原因を突き止めるには至りませんでした。

4.10. 2017年度検証の残課題
昨年度はバージョン 9.6 と比較した 10 の更新系性能が大きく低下していることが発覚し、その原因をデフォルトセマフォの変更(System V → PO SIX)によるものであると推測するところまで行いました。今回これを立証するために検証を行いました。
検証に用いたビルドのバージョンは昨年度検証と同じ 9.6.6, 10.1 および旧デフォルトセマフォの System V を指定してビルドした 10.1 を用いました。
バージョン 10 以降はソースコードの src/temp late/lin u x の以下の箇所を削除することで、利用するセマフォを System V に変更することができます。

# Prefer unnamed POSIX semaphores if available, unless user overrides choice
if test x"$PREFERRED_SEMAPHORES" = x"" ; then
PREFERRED_SEMAPHORES=UNNAMED_POSIX
fi

Page 19 of 67

PostgreSQL Enterprise Consortium
セマフォの設定が変わったどうかは co n figu re 実行後の co n fig.lo g から確認できます。(以下は10.6 の例です)[PO SIX セマフォが設定されている場合]$ cat postgresql-10.6/config.log | grep -A 1 semaphore
configure:15720: checking which semaphore API to use
configure:15743: result: unnamed POSIX[System V セマフォが設定されている場合]$ cat postgresql-10.6x/config.log | grep -A 1 semaphore
configure:15720: checking which semaphore API to use
configure:15743: result: System V

System V セマフォを用いた 9.6.6, PO SIX セマフォを用いた 10.1, SYSV セマフォを用いた 10.1 の各パフォーマンスを比較した結果は以下の通りです。

図 4.7 セマフォとバージョンの組み合わせごとのパフォーマンス比較
この結果から、同じバージョン 10 でも使用するセマフォを PO SIX から 9.6 と同じ System V に戻せばパフォーマンスも同程度に戻ることが確認できました。
ところで、10.5 の リリースノート には以下のような記述があります。

Pad arrays o f u n n amed PO SIX semap h o res to redu ce cach e lin e sh arin g (Th o mas Mu n ro ) Th is redu ces co n ten tio n o n man yPage 20 of 67

PostgreSQL Enterprise Consortium

CPU systems, fixin g a p erfo rman ce regressio n (co mp ared to p revio u s releases) o n Lin u x an d FreeB SD.
「キャッシュライン共用を減らすために、無名PO SIXセマフォの配列を埋めこむようになりました。これは多CPU システムでの競合を減らし、Lin u x とFreeB SD での旧リリースと比較しての性能退行を修正します。」
実は、この修正によりバージョン 10.5 以降は PO SIX セマフォを利用していても 9.6 のパフォーマンスを実現できるようになっています。この修正について実際に確認してみたものが以下の結果です。（検証で使用したのは10.6 です）

図 4.8 セマフォとバージョンの組み合わせごとのパフォーマンス比較
ご覧の通り、PO SIX セマフォを用いた 10.1 のみ性能が低く、それ以外のビルドは同程度の性能を発揮しています。これにより、10.0 当初のデフォルトセマフォの変更による性能低下は後のマイナーバージョンで修正されていることが確認できました。

4.11. まとめ
本検証では例年通り、Po stgreSQL 最新バージョンと旧バージョンとのスケールアップ性能比較検証を行いました。
参照系については、例年利用しているクエリでは性能向上が見られましたが、原因を突き詰めてみると、それは集約計算を含むことが原因でした。集約計算を外したクエリにおいては新旧での性能差は見られませんでした。
更新系については、11 の性能が 10 から向上している様子が確認できました。また、性能向上の大きな要因が clo g の更新のグループ化によることを証明できました。

2017 年度検証の残課題については、10 の更新性能低下の原因が、当時の予想通りデフォルトセマフォの変更によるものであることを証明することができました。また、デフォルトセマフォが変更されたバージョン 10 においても 10.5 以降のマイナーバージョンで性能修正がなされていることが確認できました。

Page 21 of 67

PostgreSQL Enterprise Consortium

5. Windows版 PostgreSQL性能検証
5.1. 検証概要
本章では、W in do w s 版Po stgreSQL の性能を測定し、Lin u x 版Po stgreSQL との性能の傾向を比較した結果を示します。
昨年度の成果報告として、W in do w s 版Po stgreSQL を用いた性能検証は実施したところ多くの反響をいただいたため、 今年度のPG ECo n s でも継続して、Lin u x 上で実施していた定点観測と同様の測定をW in do w s 版Po stgreSQL でも実施し、Lin u x 版Po stgreSQL 11 とW in do w s 版Po stgreSQL 11 の性能の傾向を評価しました。

5.2. 検証構成
本節では、W in do w s 版Po stgreSQL 検証の環境を説明します。

5.2.1. ハー ドウ ェア構成

図 5.1 検証ハードウェア構成
本検証では上図構成のうち「 DB サーバ#1 」と「負荷掛け用」を用いました。

5.2.2. ソフトウ ェア構成

Page 22 of 67

PostgreSQL Enterprise Consortium
検証環境のソフトウェア構成を示します。
表 5.1 DB サーバ#1

OS

W in do w s Server 2012 R2 Stan dard Editio n

Po stgreSQL

11.1 (EDB in staller 版/B igSQL in staller 版)
表 5.2 負荷掛け用

OS

Red Hat Red Hat En terp rise Lin u x 7.5

Po stgreSQL

11.1 (ソースビルド版)

5.3. 検証モデル
本節では、W in do w s 版Po stgreSQL 検証のモデルを説明します。 検証モデルの内容については、「定点観測(スケールアップ検証)」を参考にしてください。

5.3.1. デ ー タベ ー スクラスタ構成
W in do w s 版Po stgreSQL をインストーラでインストールすると、インストール中にデフォルトのデータベースクラスタを作成します。 今回の性能検証では、データベースクラスタ
を外部ストレージには配置せず、またデータベース格納領域とW AL 格納領域の分離は行わない構成で実施しています。

5.3.2. 検証用ベ ン チマー ク
検証用のベンチマークとして、Po stgreSQL 標準のベンチマークツールp gb en ch を使用しました。 （ p gb en ch の詳細については、「定点観測(スケールアップ検証)」を参考にしてください。

5.3.2.1. 初期データ 登録
初期データの登録は、p gb en ch の-i オプションでスケールファクタ = 2000 のサイズを指定しました。 fillfacto r の設定はデフォルト(テーブルのfillfacto r= 100)、u n lo gged
tab le の指定はなしとしました。

5.3.3. 仮測定
本測定の前に、インストールした Po stgreSQL が正常に動作することを確認するため、仮測定を行いました。 ここで、参照系の性能結果に異常が見られたため本検証ではEDB in staller 版ではなく、B igSQL in staller 版を用いることとしました。

5.3.3.1. 参照系仮測定
走行時間は60 秒を指定しました。 同時実行数として 1, 2, 4, 8, 16, 32, 48, 64, 96 を与えて実行しました。 参照系測定のために、以下のカスタムクエリをp gb en ch に与えて実行しました。

\set naccounts 100000 * :scale\set row_count 10000\set aid_max :naccounts - :row_count\set aid random(1, :aid_max)
SELECT count(abalance) FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count;

仮測定時の参照系検証結果(tp s)を以下に示します。

Page 23 of 67

PostgreSQL Enterprise Consortium

上記の通り、EDB in staller 版Po stgreSQL11.1 では思ったような負荷がかかっておらず、バージョン間の性能観測を行うことは困難と判断しました。 代替として B igSQL
in staller 版のPo stgreSQL11.1 ではEDB in staller 版Po stgreSQL11.1 と同等（もしくはそれ以上）の性能が出ることが確認できたため、以降の検証のPo stgreSQL
バージョンとしては、B igSQL in staller 版Po stgreSQL 11 を利用することとしました。

5.3.3.2. 更新系仮測定
走行時間は60 秒を指定しました。 同時実行数として 1, 2, 4, 8, 16, 32, 48, 64, 96 を与えて実行しました。 更新系測定のために、以下のカスタムクエリをp gb en ch に与えて実行しました。

\set naccounts 100000 * :scale\set aid_val random(1, :naccounts)
UPDATE pgbench_accounts SET filler=repeat(md5(current_timestamp::text),2) WHERE aid = :aid_val;

仮測定時の更新系検証結果(tp s)を以下に示します。

上記の仮測定の結果を確認し、B igSQL in staller 版を用いて、参照系・更新系ともに Lin u x 版Po stgreSQL との比較を行う方針としました。

5.3.3.3. バグレポート
EDB 版インストーラでインストールしたバイナリを用いた参照系測定を実施したときに、スループットが低くなる事象については、Po stgreSQL 開発コミュニティに、バグレポート
として報告しました。 h ttp s://w w w .p o stgresql.o rg/message-id/15610-f5b 6c1e204660ace%40p o stgresql.o rg このバグレポートに関する議論はあり、翌月のマイナーバージョンアップに伴い新しい版のEDB 版インストーラもリリースされましたが、その版に対応したインストーラがこの問題に対応していたのかはPG ECo n s 側では未確認です。
追記：本資料発表後、EDB in staller 版Po stgreSQL11.3 では性能に問題ないことがEn terp riseDB 社により確認済み。

5.3.4. 本測定
本測定では測定時間を300 秒として、仮測定と同様の測定を実行しました。

Page 24 of 67

PostgreSQL Enterprise Consortium

5.3.5. PostgreSQL 設定
Po stgreSQL 設定ファイル p o stgresql.co n f での設定は以下の通りです。これらは参照系検証と更新系検証で共通です。

listen_addresses = '*' ... 負荷掛け用マシンからの接続用
max_connections = 500 ... 多めに設定
shared_buffers = 16384 ... Windows版ではshared_buffersに大きな値を設定しても意味がないため
work_mem = 1GB
maitenance_work_mem = ... Windows版PostgreSQLでは上限値がLinux版よりも小さいため、20GBではなく 6GBを設定した。
checkpoint_timeout = 60min
max_wal_size = 160GB

5.3.6. OSリ ソー ス情報の 収集
Lin u x で使われているvmstat/sar といった O S のリソース情報の取得コマンドはW in do w s にはありません。 代わりに typ ep erf コマンドでO S のリソース情報を取得します。 リ
ソースがどのように利用されているかを記録するためtyp ep erf コマンドを参照系・更新系それぞれで以下の通り実行しました。 今回の検証では、typ ep erf コマンドを以下のように実行することで、CPU 使用率、メモリ使用量、ディスクへの秒あたりの書き込み量を取得するようにしました。

typeperf -sc 900 -si 10 "\processor information(_Total)\% Processor Time" "\Memory\Committed
Bytes" "\LogicalDisk(C:)\Avg. Disk sec/Read" "\LogicalDisk(C:)\Avg. Disk sec/Write" >select-res.txt
typeperf -sc 2300 -si 10 "\processor information(_Total)\% Processor Time" "\Memory\Committed
Bytes" "\LogicalDisk(C:)\Avg. Disk sec/Read" "\LogicalDisk(C:)\Avg. Disk sec/Write" >update-res.txt

5.4. 検証結果
本節では、W in do w s 版Po stgreSQL 検証結果を示します。

5.4.1. 参照系
参照系検証結果(tp s)を以下に示します。

参照系検証時の平均CPU 使用率を以下に示します。

Page 25 of 67

PostgreSQL Enterprise Consortium

参照系については同時接続数32 までは、同時接続数を上げることでほぼ線形に tp s が増加していきます。 同時接続数32 ～64 の区間では、tp s は変わらず、レイテンシが増加するという傾向になりました。 この区間では、Lin u x 版Po stgreSQL 11 よりも高いtp s となっています。 この区間で、W in do w s 版Po stgreSQL のtp s がLin u x 版
Po stgreSQL よりも高いtp s になっている原因については、現時点では不明であり、今後の課題と考えています。 Lin u x 版Po stgreSQL とW in do w s 版Po stgreSQL のCPU の使用状況を比較してみると、Lin u x 版Po stgreSQL でもCPU は十分に使われており、 CPU の使用状況が原因ではないと考えられます。 今後、どういった情報を収集して Lin u x 版Po stgreSQL との挙動を比較すれば良いかも含めて検討が必要です。
同時実行数が64 を超えると急激に tp s が低下し、また CPU 使用率も大きく減少しています。 このとき、Lin u x 版Po stgreSQL 11 よりもtp s は悪化し、また CPU 使用率についてもLin u x 版Po stgreSQL と比較すると大きく低下するという結果になっています。
過負荷状態では、CPU ネックとは別の原因がネックになっていると考えられます。プロセス間の排他待ちの影響がLin u x 版と比較すると大きくなっていると推測していますが、今年度の測定では、それを示す情報の取得はできませんでした。 次年度の測定では、同時接続数が過大になったときのtp s およびCPU 使用率の低下原因の追求が必要と考えます。

5.4.2. 更新系
更新系検証結果(tp s)を以下に示します。

更新系検証時の平均CPU 使用率を以下に示します。

Page 26 of 67

PostgreSQL Enterprise Consortium

更新系に関しては、同時接続数32 でtp s のピーク値となり、以降はほぼtp s は横ばいとなりました。 Lin u x 版と比較すると、同時接続数48 以降は大きく tp s が小さくなるという結果になっています。 更新系の平均CPU 使用率を見ると、参照系とは異なり、同時接続数64 をピークとして最大でも30% 程度の使用率となっています。 また、Lin u x
版更新系の平均使用率と比較すると、全般に CPU 使用率が低い傾向にあります。 このことから、W in do w s 環境では更新時のI/O 負荷がLin u x と比較して高いことが推測されます。

5.5. まとめ
定点観測モデルを用いて、W in do w s 版Po stgreSQL とLin u x 版Po stgreSQL の性能を比較しました。
参照系の場合、同一スペックのサーバ上でLin u x/W in do w s のO S の差異による測定を実施した結果、CPU 数を超えない範囲の同時接続数であれば、Lin u x 版と同等
あるいは上回る性能となりました。ただし、CPU 数を超えた同時接続数になると急速に性能が劣化します。 この原因が検証に使用したバイナリ(EDB 版/B igSQL 版)の違いによるものか、Po stgreSQL バージョンによるものか、その違いを調査することも今後の課題と考えます。
更新系の場合、同一スペックのサーバ上でLin u x/W in do w s のO S の差異による測定を実施した結果、同時接続数が32 を超える場合に、Lin u x 版と比較してW in do w s 版のtp s が大きく劣るという結果となりました。この原因については、I/O 性能の差が原因と想定していますが、それを示すO S リソース値の取得が今後の課題と考えます。また、今回はデータ格納用のディスクと更新ログ格納用のディスクを同居した構成にしていましたが、データ格納用のディスクと更新ログ格納用のディスクを分離した場合の測定も、次年度以降検討したいと考えます。

Page 27 of 67

PostgreSQL Enterprise Consortium

6. JITコンパイル 性能検証
6.1. 検証概要
Po stgreSQL 11 に実行時(Ju st-In -Time; JIT)コンパイルが実装されました。JITコンパイルの目的はクエリの実行速度を向上させることです。 クエリプランの一部分に対して
JITコンパイルを実行することで実現されます。 本検証では、JITコンパイルが有効に働くクエリ種を調査するとともに、それによって実行時間がどれだけ削減されるか検証します。
検証用データベースに Star Sch ema B en ch mark(SSB ) を採用し、以下の検証と考察を実施しました。
演算、関数ごとのJITコンパイルの有効性の検証
データ型によるJITコンパイルの有効性の差異の検証
SSB クエリを用いた JITコンパイルの有効性の検証

6.2. JITコンパイルとは
6.2.1. JIT コン パイル
JITコンパイルとは、ソフトウェアの実行時にコードのコンパイルを行い実行速度の向上を図る手法です。 反復される処理を、インタプリタ形式からコンパイルしてバイナリを実行する形式に変更することで高速化を実現しています。

6.2.2. PostgreSQL で の JIT コン パイル
Po stgreSQL でJITコンパイルを利用可能にするためには、以下のパッケージが必要になります。
表 6.1 追加パッケージ
パッケ ージ名

llvm ライブラリ

最低限必要なバージョ ン

3.9

clan g （ clan g 互換のコンパイラ） 3.9
C+ + コンパイラなし

上記パッケージがインストールされた状態でPo stgreSQL のビルド時に "--w ith -llvm"を指定することにより、LLVM を使った JITコンパイルが組み込まれます。 具体的な方法
は、SRA O SS 社が公開している Po stgreSQL11 検証報告書 をご参照ください。
高速化の対象として、W HERE 句やターゲットリスト、集約関数などといった式の評価やディスク上のタプルをインメモリ形式に変換するタプル変形、そして関数のインライン化があります。 インライン化はクエリ中の関数呼び出しや演算子をバイナリに変換し、関数呼び出しのオーバーヘッドを削減します。 JITコンパイルが有効に働く状況は、CPU
使用率の高い状態が長時間継続するようなクエリを実行している状態とされています。 つまり、式表現が複雑であり、参照する行数が多い解析系のクエリで有効であるといえます。 逆に、短時間で完了するクエリではJITのオーバーヘッドの方が大きくなってしまいます。（下記の実行計画例を参照）

JITコンパイルを有効にするには、p o stgresql.co n f ファイルのjit パラメータ（後述）をo n に設定する必要があります。 さらに、JITコンパイルが実行されるか否かは、クエリのコストに依存します。 コストはjit_ab o ve_co st パラメータ（後述）で与えられる閾値と比較され、コストの方が大きければJITコンパイルが実行されます。 JITコンパイルが実行される場合、jit_in lin e_ab o ve_co st パラメータ（後述）の閾値およびjit_o p timize_ab o ve_co st パラメータ（後述）の閾値と比較され、コストの方が大きければ関数のインライン化または最適化がそれぞれ追加で実行されます。

JITコンパイルの実行状況は、実行計画から確認できます。
QUERY PLAN------------------------------------------------------------------------------------------------------------Aggregate (cost=16.27..16.29 rows=1 width=8) (actual time=6.049..6.049 rows=1 loops=1)-> Seq Scan on pg_class (cost=0.00..15.42 rows=342 width=4) (actual time=0.019..0.052 rows=356 loops=1)
Planning Time: 0.133 ms
JIT:
Functions: 3
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 1.259 ms, Inlining 0.000 ms, Optimization 0.797 ms, Emission 5.048 ms, Total 7.104 ms
Execution Time: 7.416 ms「 JIT: 」以下に実行した JITコンパイルの詳細が表示されます。

Page 28 of 67

PostgreSQL Enterprise Consortium
表 6.2 実行計画に表示されるJITコンパイルの実行状態
項目

説明

Fu n ctio n s JITコンパイルによって処理された関数の数O p tio n

実行された JIT処理（ b o o l 型で表示）
In lin in g ：インライン化
O p timizatio n ：最適化
Exp ressio n s ：式の評価
Defo rmin g ：タプルの変換

Time

一連の処理で要した時間
G en eratio n ： JITコンパイルの所要時間
In lin in g ：インライン化所要時間
O p timizatio n ：最適化所要時間
Emissio n ： JITコード出力所要時間
To tal ：上記の合計時間

6.2.3. JIT コン パイル に関するパラメー タ
JITコンパイル時に関連する主なパラメータには以下があります。
表 6.3 JITコンパイルに関連する主なパラメータパラ メ ータ

デフォルト 値

説明

jit

o ff

JITコンパイルを使用するかどうか

jit_ab o ve_co st

100000

JITコンパイルを使用するコストの閾値

jit_in lin e_ab o ve_co st

500000関数のインライン化を使用するコストの閾値

jit_o p timize_ab o ve_co st 500000

積極的な最適化を使用するコストの閾値

6.3. 検証構成
6.3.1. 検証ハー ドウ ェア環境
検証環境のハードウェア構成の概略を示します。
表 6.4 検証用DB サーバ構成
機器

項目

検証サーバ（ PRIMERG Y
RX2540M4 ）

仕様

CPU

インテル Xeo n G o ld 6140 ＠2.30G Hz
18 コア x2 合計 36 コア
ハイパースレッディング:o ff

搭載メモリ

256G B

内蔵ストレージ

HDD 700G B

6.3.2. 検証ソフトウ ェア環境
検証環境のソフトウェア環境を示します。
表 6.5 ソフトウェア構成
種類

ソフト ウェ ア名およびバージョ ン

OS

Red Hat En terp rise Lin u x
7.5

Datab ase

Po stgreSQL 11.1

6.4. 検証方法
6.4.1. 検証項目
JITコンパイル検証では以下の3 点を検証します。
6.4.1.1. 検証 1
検証1 では、単一の演算、関数を含むクエリを用いた際のJITコンパイルの有効性を確認します。 使用する演算、関数は以下とします。

Page 29 of 67

PostgreSQL Enterprise Consortium

表 6.6 検証1 で使用する演算と関数演算の種類使用する演算

四則演算

乗算(× )、減算(-)

集約関数

su m, avg, co u n t, max

統計処理用の集約関数

stddev, var_samp

四則演算は、パラレルクエリ検証でも用いられた SSB のクエリに含まれるものを抜粋しました。 集約関数については、JITコンパイルは集約に効果があるとの記載 [1] から検証に使用しています。 また、集約関数の分け方はPo stgreSQL 文書に基づいたものです。 これにより、単純な演算を含むクエリでのJITコンパイルによってどれほど実行時間が削減されるかを明らかにします。

[1] Po stgreSQL 11 文書 第32 章 実行時コンパイル(JIT) 32.1.1. JITにより高速化される処理
6.4.1.2. 検証 2
検証2 では、データ型によって JITコンパイルの効果が変化するか検証します。 使用するデータ型は、in teger 型、n u meric 型、real 型、do u b le p recisio n 型です。 これにより、データ型の違いでJITコンパイルによる実行時間の削減量がどれほど変わるのかを明らかにします。

6.4.1.3. 検証 3
検証3 では、SSB のクエリを用いて、JITコンパイルを用いた場合と用いない場合でどれほどの差が出るか検証します。 これにより、O LAP 系の実用的なクエリを実行した際にJITコンパイルによって実行時間がどれほど削減されるかを明らかにします。

6.4.2. デ ー タモデ ル
本検証で使用するデータモデルは、Star Sch ema B en ch mark(SSB )に準拠します。 データの生成プログラムは、 こちらのG itHu b リポジトリ から入手したものを使用しました。 また、テーブル定義は こちら から入手したものを使用しました。

# zipファイルを解凍する$ bzip2 -d ssb.tar.bz2$ tar xf ssb.tar$$ make# データ生成（ -sはスケールファクタ（後述）を指定するオプション、-Tはテーブルの種類を指定するオプション）$ ./dbgen -s 1 -T c #customerテーブル$ ./dbgen -s 1 -T d #dateテーブル$ ./dbgen -s 1 -T l #lineorderテーブル$ ./dbgen -s 1 -T p #partテーブル$ ./dbgen -s 1 -T s #supplierテーブル# テーブルを定義する(コマンドは省略）# テーブルにデータを挿入する（以下のコマンドを各テーブルごとに実行する）$ sed -e 's/|$//' customer.tbl | psql -d jit-test -c "copy customer from STDIN ( delimiter '|');"SSB はその名前の通り、スター・スキーマ型のデータモデルを採用しています。 スタースキーマ型のデータモデルは、1 つのファクトテーブルと複数のディメンジョンテーブルで構成されています。 ファクトテーブルとは分析対象となる実績値が格納される明細データであり、データ件数は億単位（本検証では約6 億件）になります。 ディメンジョンテーブルとはビジネス上の分析の軸になるマスターデータであり、データ件数は少ないのが特徴です。 SSB ではlin eo rder テーブルがファクトテーブルであり、商品の購入履歴が時系列に蓄積されます。 そして SSB のディメンジョンテーブルにはcu sto mer テーブル、su p p lier テーブル、p art テーブル、date テーブルがあり、顧客やサプライヤなどの識別キーや名称などが格納されます。

Page 30 of 67

PostgreSQL Enterprise Consortium

図 6.1 Star Sch ema B en ch mark のテーブル構成
なお、Scale Facto r= 100G B としています。 Scale Facto r(SF)とは、ベンチマーク全体のテーブル規模を示しています。 SSB で使用されるテーブルの行数はSF によって以下のように計算できます。 date テーブルは7 年分の日付情報を持つため、常に一定の大きさになっています。
表 6.7 検証に使用するテーブルの規模

relnamerows

cu sto mer

SF × 30000

date

2556

lin eo rder

SF × 6000000

p art

200000 × (1+ lo g2(SF)) (小数点切り捨て )su p p lierSF × 10000

本検証における各テーブルのサイズは以下の通りです。

Page 31 of 67

PostgreSQL Enterprise Consortium

relname
|
rows
|
bytes
-----------------------+------------+-------------customer| 3000000| 374030336
date| 2315| 311296
lineorder| 599985000 | 63557517312
part| 1399570| 164265984
supplier| 999604| 114376704

6.4.3. DB設定
性能測定にあたり、デフォルトから変更したパラメータは以下のとおりです。 本検証ではJITコンパイルの性能を確認するため、パラレルクエリとして実行されないように
max_p arallel_w o rkers_p er_gath er パラメータの値を0 としています。
表 6.8 デフォルトから変更したパラメータパラ メ ータ

設定値

sh ared_b u ffers

64G B

w o rk_mem

2G Bmain ten an ce_w o rk_mem

32G B

max_p arallel_w o rkers_p er_gath er 0
w al_level

rep lica

max_w al_size

10G B

min _w al_size

800MB

6.4.4. 測定手順
測定に際しては、SQL の実行前に p g_p rew arm を利用して、テーブルのデータをディスクから一度読込み、Po stgreSQL のバッファ上、もしくはO S のディスクバッファ上に常駐させた状態にします。

SELECT relname, pg_prewarm(oid)
FROM pg_class
WHERE relnamespace in (SELECT oid
FROM pg_namespace
WHERE nspname='public') AND (
relkind='r');
6.4.4.1. 検証 1 測定方法
以下のSQL を、p sql を用いて実行します。
乗算

select lo_extendedprice * lo_discountfrom lineorder;
減算

select lo_revenue - lo_supplycost
from lineorder;
su m

select sum(lo_extendedprice)from lineorder;
avg

Page 32 of 67

PostgreSQL Enterprise Consortium

select avg(lo_extendedprice)from lineorder;
co u n t

select count(lo_extendedprice)from lineorder;
co u n t(*)

select count(*)
from lineorder;
max

select max(lo_extendedprice)from lineorder;
stddev

select stddev(lo_extendedprice)from lineorder;
var_samp

select var_samp(lo_extendedprice)from lineorder;
6.4.4.2. 検証 2 測定方法
以下のSQL を、p sql を使用して実行します。 本検証で用いるテーブルlin eo rder_n , lin eo rder_r, lin eo rder_d は、lin eo rder テーブルのlo _exten dedp rice カラムのデータ型をin teger 型から n u meric 型、real 型、do u b le p recisio n 型にそれぞれ変更したものです。

n u meric 型

select sum(lo_extendedprice)from lineorder_n;real 型

select sum(lo_extendedprice)from lineorder_r;
do u b le p recisio n 型

select sum(lo_extendedprice)from lineorder_d;
6.4.4.3. 検証 3 測定方法
以下のSSB のクエリを、p sql を使用して実行します。

6.4.4.3.1. No.1

No .1 のクエリは、ある年の商品出荷において割引を廃止した場合に発生する収益の増加量を求めます。
No .1-1

Page 33 of 67

PostgreSQL Enterprise Consortium

select sum(lo_extendedprice * lo_discount) as revenue
from lineorder, datewhere lo_orderdate = d_date_key andd_year = 1993 andlo_discount between 1 and 3 andlo_quantity < 25;
No .1-2

select sum(lo_extendedprice * lo_discount) as revenue
from lineorder, datewhere lo_orderdate = d_date_key andd_yearmonthnum = 199401 andlo_discount between 4 and 6 andlo_quantity between 26 and 35;
No .1-3

select sum(lo_extendedprice * lo_discount) as revenue
from lineorder, datewhere lo_orderdate = d_date_key andd_weeknuminyear = 6 andd_year = 1994 andlo_discount between 5 and 7 andlo_quantity between 26 and 35;
6.4.4.3.2. No.2

No .2 のクエリは、納入元の地域、商品カテゴリの観点から発注年と商品分類でグループ化した収益を求めます。
No .2-1

select sum(lo_revenue), d_year, p_brand1
from lineorder, date, part, supplierwhere lo_orderdate = d_datekey andlo_partkey = p_partkey andlo_suppkey = s_suppkey andp_category = 'MFGR#12' ands_region = 'AMERICA'
group by d_year, p_brand1
order by d_year, p_brand1;
No .2-2

select sum(lo_revenue), d_year, p_brand1
from lineorder, date, part, supplierwhere lo_orderdate = d_datekey andlo_partkey = p_partkey andlo_suppkey = s_suppkey andp_brand1 between 'MFGR#2221' and 'MFGR#2228' ands_region = 'ASIA'
group by d_year, p_brand1
order by d_year, p_brand1;
No .2-3

Page 34 of 67

PostgreSQL Enterprise Consortium

select sum(lo_revenue), d_year, p_brand1
from lineorder, date, part, supplierwhere lo_orderdate = d_datekey andlo_partkey = p_partkey andlo_suppkey = s_suppkey andp_brand1 = 'MFGR#2221' ands_region = 'EUROPE'
group by d_year, p_brand1
order by d_year, p_brand1;
6.4.4.3.3. No.3

No .3 のクエリは、ある特定の期間と地域における顧客の国、納入元の国、発注年でグループ化した収益を求めます。
No .3-1

select c_nation, s_nation, d_year, sum(lo_revenue) as revenue
from customer, lineorder, supplier, datewhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_orderdate = d_datekey andc_region = 'ASIA' ands_region = 'ASIA' andd_year between 1992 and 1997
group by c_nation, s_nation, d_year
order by d_year asc, revenue desc;
No .3-2

select c_city, s_city, d_year, sum(lo_revenue) as revenue
from customer, lineorder, supplier, datewhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_orderdate = d_datekey andc_nation = 'UNITED STATES' ands_nation = 'UNITED STATES' andd_year between 1992 and 1997
group by c_city, s_city, d_year
order by d_year asc, revenue desc;
No .3-3

select c_city, s_city, d_year, sum(lo_revenue) as revenue
from customer, lineorder, supplier, datewhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_orderdate = d_datekey and( c_city = 'UNITED KI1' orc_city = 'UNITED KI5') and( s_city = 'UNITED KI1' ors_city = 'UNITED KI5') andd_year between 1992 and 1997
group by c_city, s_city, d_year
order by d_year asc, revenue desc;
No .3-4

Page 35 of 67

PostgreSQL Enterprise Consortium

select c_city, s_city, d_year, sum(lo_revenue) as revenue
from customer, lineorder, supplier, datewhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_orderdate = d_datekey and( c_city = 'UNITED KI1' orc_city = 'UNITED KI5') and( s_city = 'UNITED KI1' ors_city = 'UNITED KI5') andd_yearmonth = 'Dec1997'
group by c_city, s_city, d_year
order by d_year asc, revenue desc;
6.4.4.3.4. No.4

No .4 のクエリは、5 つのテーブルすべてを利用し、総計の利益を求めます。
No .4-1

select d_year, c_nation, sum(lo_revenue - lo_supplycost) as profit
from date, customer, supplier, part, lineorderwhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_partkey = p_partkey andlo_orderdate = d_datekey andc_region = 'AMERICA' ands_region = 'AMERICA' and(p_mfgr = 'MFGR#1' or
p_mfgr = 'MFGR#2')
group by d_year, c_nation
order by d_year, c_nation;
No .4-2

select d_year, s_nation, p_category, sum(lo_revenue - lo_supplycost) as profit
from date, customer, supplier, part, lineorderwhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_partkey = p_partkey andlo_orderdate = d_datekey andc_region = 'AMERICA' ands_region = 'AMERICA' and( d_year = 1997 ord_year = 1998) and(p_mfgr = 'MFGR#1' or
p_mfgr = 'MFGR#2')
group by d_year, s_nation, p_categoryorder by d_year, s_nation, p_category;No .4-3

Page 36 of 67

PostgreSQL Enterprise Consortium

select d_year, s_city, p_brand1, sum(lo_revenue - lo_supplycost) as profit
from date, customer, supplier, part, lineorderwhere lo_custkey = c_custkey andlo_suppkey = s_suppkey andlo_partkey = p_partkey andlo_orderdate = d_datekey andc_region = 'AMERICA' ands_nation = 'UNITED STATES' and( d_year = 1997 ord_year = 1998) and
p_category = 'MFGR#14'
group by d_year, s_city, p_brand1
order by d_year, s_city, p_brand1;

6.5. 検証結果
6.5.1. 検証 1
検証1 での結果を以下に示します。

図 6.2 JITコンパイルO N/O FF での実行時間の比較

Page 37 of 67

PostgreSQL Enterprise Consortium
表 6.9 JITコンパイルO N/O FF での実行時間（秒）
演算の種類

削減率 (% )JIT:OFFJIT:ON

乗算

127.560

104.274

18.254減算

125.733

101.229

19.489su m

50.01737.53524.955avg

54.46637.94630.331max

52.53335.49532.433co u n t

51.51935.67330.758co u n t(*)

25.14220.983

16.541

stddev

50.68136.60927.764

var_samp

51.83737.58827.489

削減率は、100× (t_o ff-t_o n )/(t_o ff)で求められます。 t_o ff はJITコンパイルがO FF の場合の実行時間、t_o n はJITコンパイルがO N の場合の実行時間です。 いずれの演算を含むクエリにおいても約20% ～30% 実行時間が削減され、JITコンパイルを実行したときの方が実行時間が短くなることがわかります。 乗算と減算を含むクエリの実
行時間がそのほかの演算を含むクエリの実行時間よりも長いのは、lin eo rder テーブルのもつ約6 億行のレコードごとに演算を実行した結果、約6 億行の演算結果が返却されるためと考えられます。

6.5.2. 検証 2
検証2 での結果を以下に示します。

図 6.3 JITコンパイルO N/O FF での実行時間の比較
表 6.10 JITコンパイルO N/O FF での実行時間（秒）カ ラ ムのデータ 型

JIT:OFFJIT:ON

削減率 (% )in teger 型

50.01737.53524.955n u meric 型

72.86358.91319.134

real 型

61.19739.32935.733do u b le p recisio n 型 58.886

40.94630.466

データ型によって JITコンパイルの効果に差が出ることがわかります。 特に、n u meric 型は他のデータ型に比べて実行時間が長くなっています。 これはn u meric 型が可変長サイズであるためと考えられます。

Page 38 of 67

PostgreSQL Enterprise Consortium

6.5.3. 検証 3
検証3 での結果を以下に示します。

図 6.4 JITコンパイルO N/O FF での実行時間
表 6.11 JITコンパイルO N/O FF での実行時間（秒）ク エリ N o.

JIT:OFFJIT:ON

削減率 (% )1-160.43441.01632.131

1-2

58.38640.56830.517

1-3

57.74740.73729.4562-1

82.11675.1498.485

2-2

62.75460.1744.112

2-3

50.34047.0396.557

3-1

135.593117.087

13.6483-2

64.23759.9196.721

3-3

64.23659.3187.657

3-4

53.74350.1736.643

4-1

119.962109.932

8.361

4-2

111.415

97.12912.8234-3

73.24765.111

11.108O LAP 系の実用的なクエリを実行する際にも、JITコンパイルを実行することで実行時間が短くなることが確認できました。 また、クエリによって効果に差が見られました。

6.6. 考察
検証1 、検証2 、検証3 で用いたクエリから実行計画を取得し、JITコンパイルによるオーバヘッド部分と高速化した処理を確認します。 さらに、検証3 では、削減率の低いクエリがある理由について追加調査しました。

6.6.1. 検証 1
Page 39 of 67

PostgreSQL Enterprise Consortium
検証1 においては、乗算を含むクエリとsu m 関数の含むクエリ2 種類の実行計画を確認します。

6.6.1.1. 乗算を含むク エリ
JITコンパイルがO N の場合
QUERY PLAN------------------------------------------------------------------------------------------------------------------------------Seq Scan on lineorder (cost=0.00..15259254.00 rows=600061440 width=4) (actual time=13.632..49875.825 rows=600037902 loops=1)
Buffers: shared hit=7758486
Planning Time: 0.040 ms
JIT:
Functions: 2
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 0.309 ms, Inlining 0.957 ms, Optimization 8.485 ms, Emission 4.106 ms, Total 13.857 ms
Execution Time: 66032.955 ms

JITコンパイルがO FF の場合
QUERY PLAN-----------------------------------------------------------------------------------------------------------------------------Seq Scan on lineorder (cost=0.00..15259254.00 rows=600061440 width=4) (actual time=0.006..71122.610 rows=600037902 loops=1)
Buffers: shared hit=7758486
Planning Time: 0.043 ms
Execution Time: 87332.431 ms

JITコンパイルがO N の場合では、シーケンシャルスキャンノードにおけるactu al time の左側の数値（ 1 行目の結果を受け取るのに要した時間）がJITコンパイル処理の所要時間にほぼ一致していることがわかります。 このことから、オーバーヘッド部分を確認できました。 また、actu al time からシーケンシャルスキャンの実行にかかる時間が短縮されたことでクエリの実行時間が削減されたこともわかります。

6.6.1.2. sum 関数を含むク エリ
JITコンパイルがO N の場合
QUERY PLAN-----------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=15259254.00..15259254.01 rows=1 width=8) (actual time=70981.559..70981.559 rows=1 loops=1)
Buffers: shared hit=7758486-> Seq Scan on lineorder (cost=0.00..13759100.40 rows=600061440 width=4) (actual time=0.004..27183.683 rows=600037902 loops=1)
Buffers: shared hit=7758486
Planning Time: 0.038 ms
JIT:
Functions: 3
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 0.565 ms, Inlining 1.459 ms, Optimization 20.451 ms, Emission 12.119 ms, Total 34.594 ms
Execution Time: 70982.215 ms

JITコンパイルがO FF の場合
QUERY PLAN-----------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=15259254.00..15259254.01 rows=1 width=8) (actual time=90474.587..90474.587 rows=1 loops=1)
Buffers: shared hit=7758486-> Seq Scan on lineorder (cost=0.00..13759100.40 rows=600061440 width=4) (actual time=0.004..28574.686 rows=600037902 loops=1)
Buffers: shared hit=7758486
Planning Time: 0.047 ms
Execution Time: 90474.615 ms
乗算を含むクエリとは異なり、オーバーヘッドになっている部分を特定することはできませんでした。 しかし、シーケンシャルスキャンにかかる時間はJITコンパイルのO N/O FF によらずほぼ同じだったものの、Aggregate 処理による出力が開始/完了する時間はJITコンパイルがO N の場合の方が早くなっていました。 このことから、Aggregate 処理におけるJITコンパイルの高速化度合いが、JITコンパイル自身のオーバーヘッドを上回ったと考えられます。

6.6.2. 検証 2
検証2 においては、整数型であるin teger 型とn u meric 型を設定した際の実行計画を取得しました。 in teger 型の実行計画は検証1 の考察（ su m 関数を含むクエリ）で示しているため、ここではn u meric 型の実行計画のみを示します。

JITコンパイルがO N の場合

Page 40 of 67

PostgreSQL Enterprise Consortium

QUERY PLAN-------------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=15530386.20..15530386.21 rows=1 width=32) (actual time=86556.379..86556.380 rows=1 loops=1)
Buffers: shared hit=8029987-> Seq Scan on lineorder_n (cost=0.00..14030306.36 rows=600031936 width=7) (actual time=0.005..28851.551 rows=600037902 loops=1)
Buffers: shared hit=8029987
Planning Time: 0.051 ms
JIT:
Functions: 3
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 0.557 ms, Inlining 2.549 ms, Optimization 20.533 ms, Emission 12.185 ms, Total 35.824 ms
Execution Time: 86556.987 ms

JITコンパイルがO FF の場合
QUERY PLAN-------------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=15530386.20..15530386.21 rows=1 width=32) (actual time=107847.607..107847.607 rows=1 loops=1)
Buffers: shared hit=8029987-> Seq Scan on lineorder_n (cost=0.00..14030306.36 rows=600031936 width=7) (actual time=0.004..28785.690 rows=600037902 loops=1)
Buffers: shared hit=8029987
Planning Time: 0.048 ms
Execution Time: 107847.637 ms

in teger 型のときの実行計画と同様に、オーバーヘッドになっている部分を特定することはできませんでしたが、シーケンシャルスキャンにかかる時間はJITコンパイルのO N/O FF によらずほぼ同じであり、Aggregate 処理による出力が開始/完了する時間はJITコンパイルがO N の場合の方が早くなっていました。 in teger 型とn u meric 型の間での差は、Aggregate 処理における高速化度合いの差にあることがわかります。

6.6.3. 検証 3
検証3 においては、削減率が最も高かった No .1-1 のクエリと、最も低かった No .2-2 のクエリから実行計画を取得しました。

6.6.3.1. N o.1-1
JITコンパイルがO N の場合
QUERY PLAN------------------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=18719494.34..18719494.35 rows=1 width=8) (actual time=44864.530..44864.530 rows=1 loops=1)
Buffers: shared hit=7758524-> Hash Join (cost=74.19..18663739.86 rows=11150896 width=8) (actual time=112.756..44343.859 rows=11913972 loops=1)
Hash Cond: (lineorder.lo_orderdate = date.d_datekey)
Buffers: shared hit=7758524-> Seq Scan on lineorder (cost=0.00..18259561.20 rows=78025470 width=12) (actual time=112.507..39017.385 rows=78550619 loops=1)
Filter: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
Rows Removed by Filter: 521487283
Buffers: shared hit=7758486-> Hash (cost=69.66..69.66 rows=362 width=4) (actual time=0.225..0.226 rows=365 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 21kB
Buffers: shared hit=38-> Seq Scan on date (cost=0.00..69.66 rows=362 width=4) (actual time=0.043..0.188 rows=365 loops=1)
Filter: (d_year = 1993)
Rows Removed by Filter: 2191
Buffers: shared hit=38
Planning Time: 0.101 ms
JIT:
Functions: 18
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 1.511 ms, Inlining 1.941 ms, Optimization 72.381 ms, Emission 38.003 ms, Total 113.835 ms
Execution Time: 44866.132 ms

JITコンパイルがO FF の場合

Page 41 of 67

PostgreSQL Enterprise Consortium

QUERY PLAN----------------------------------------------------------------------------------------------------------------------------------------Aggregate (cost=18719494.34..18719494.35 rows=1 width=8) (actual time=64377.092..64377.093 rows=1 loops=1)
Buffers: shared hit=7758524-> Hash Join (cost=74.19..18663739.86 rows=11150896 width=8) (actual time=0.242..63766.864 rows=11913972 loops=1)
Hash Cond: (lineorder.lo_orderdate = date.d_datekey)
Buffers: shared hit=7758524-> Seq Scan on lineorder (cost=0.00..18259561.20 rows=78025470 width=12) (actual time=0.006..58183.140 rows=78550619 loops=1)
Filter: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
Rows Removed by Filter: 521487283
Buffers: shared hit=7758486-> Hash (cost=69.66..69.66 rows=362 width=4) (actual time=0.232..0.232 rows=365 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 21kB
Buffers: shared hit=38-> Seq Scan on date (cost=0.00..69.66 rows=362 width=4) (actual time=0.033..0.202 rows=365 loops=1)
Filter: (d_year = 1993)
Rows Removed by Filter: 2191
Buffers: shared hit=38
Planning Time: 0.102 ms
Execution Time: 64377.128 ms

No .1-1 のクエリでは、lin eo rder テーブルにおけるシーケンシャルスキャン処理部分に JITコンパイルによるオーバーヘッドが発生していますが、高速化されていることもわかります。 また、JITコンパイルによるオーバーヘッドはある1 つの処理（ No .1-1 のクエリではlin eo rder テーブルにおけるシーケンシャルスキャン処理）にのみ発生していることもわかります。

6.6.3.2. N o.2-2
JITコンパイルがO N の場合
QUERY PLAN-----------------------------------------------------------------------------------------------------------------------------------------------------------GroupAggregate (cost=16129050.94..16131822.99 rows=6713 width=21) (actual time=88508.083..88720.456 rows=56 loops=1)
Group Key: date.d_year, part.p_brand1
Buffers: shared hit=7792538-> Sort (cost=16129050.94..16129727.17 rows=270492 width=17) (actual time=88505.310..88627.316 rows=961749 loops=1)
Sort Key: date.d_year, part.p_brand1
Sort Method: quicksort Memory: 99713kB
Buffers: shared hit=7792538-> Hash Join (cost=70125.25..16104645.50 rows=270492 width=17) (actual time=1050.155..87659.761 rows=961749 loops=1)
Hash Cond: (lineorder.lo_orderdate = date.d_datekey)
Buffers: shared hit=7792538-> Hash Join (cost=70030.26..16100831.24 rows=270492 width=17) (actual time=750.644..87139.416 rows=961749 loops=1)
Hash Cond: (lineorder.lo_suppkey = supplier.s_suppkey)
Buffers: shared hit=7792500-> Hash Join (cost=41091.26..16064069.52 rows=1364746 width=21) (actual time=622.302..84999.357 rows=4813031 loops=1)
Hash Cond: (lineorder.lo_partkey = part.p_partkey)
Buffers: shared hit=7778538-> Seq Scan on lineorder (cost=0.00..13759100.40 rows=600061440 width=16) (actual time=0.014..30166.398 rows=600037902 loops=1)
Buffers: shared hit=7758486-> Hash (cost=41051.46..41051.46 rows=3184 width=13) (actual time=622.161..622.161 rows=11270 loops=1)
Buckets: 16384 (originally 4096) Batches: 1 (originally 1) Memory Usage: 657kB
Buffers: shared hit=20052-> Seq Scan on part (cost=0.00..41051.46 rows=3184 width=13) (actual time=0.051..620.122 rows=11270 loops=1)
Filter: (((p_brand1)::text >= 'MFGR#2221'::text) AND ((p_brand1)::text <= 'MFGR#2228'::text))
Rows Removed by Filter: 1388730
Buffers: shared hit=20052-> Hash (cost=26461.59..26461.59 rows=198193 width=4) (actual time=127.785..127.785 rows=199889 loops=1)
Buckets: 262144 Batches: 1 Memory Usage: 9076kB
Buffers: shared hit=13962-> Seq Scan on supplier (cost=0.00..26461.59 rows=198193 width=4) (actual time=0.016..102.187 rows=199889 loops=1)
Filter: ((s_region)::text = 'ASIA'::text)
Rows Removed by Filter: 800111
Buffers: shared hit=13962-> Hash (cost=63.33..63.33 rows=2533 width=8) (actual time=299.477..299.477 rows=2556 loops=1)
Buckets: 4096 Batches: 1 Memory Usage: 132kB
Buffers: shared hit=38-> Seq Scan on date (cost=0.00..63.33 rows=2533 width=8) (actual time=298.936..299.241 rows=2556 loops=1)
Buffers: shared hit=38
Planning Time: 0.190 ms
JIT:
Functions: 46
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 2.996 ms, Inlining 3.770 ms, Optimization 194.606 ms, Emission 100.255 ms, Total 301.627 ms
Execution Time: 88729.503 ms

Page 42 of 67

PostgreSQL Enterprise Consortium

JITコンパイルがO FF の場合
QUERY PLAN-----------------------------------------------------------------------------------------------------------------------------------------------------------GroupAggregate (cost=16129050.94..16131822.99 rows=6713 width=21) (actual time=94027.557..94265.541 rows=56 loops=1)
Group Key: date.d_year, part.p_brand1
Buffers: shared hit=7792538-> Sort (cost=16129050.94..16129727.17 rows=270492 width=17) (actual time=94024.314..94150.612 rows=961749 loops=1)
Sort Key: date.d_year, part.p_brand1
Sort Method: quicksort Memory: 99713kB
Buffers: shared hit=7792538-> Hash Join (cost=70125.25..16104645.50 rows=270492 width=17) (actual time=779.793..93198.298 rows=961749 loops=1)
Hash Cond: (lineorder.lo_orderdate = date.d_datekey)
Buffers: shared hit=7792538-> Hash Join (cost=70030.26..16100831.24 rows=270492 width=17) (actual time=779.182..92970.569 rows=961749 loops=1)
Hash Cond: (lineorder.lo_suppkey = supplier.s_suppkey)
Buffers: shared hit=7792500-> Hash Join (cost=41091.26..16064069.52 rows=1364746 width=21) (actual time=636.921..90822.476 rows=4813031 loops=1)
Hash Cond: (lineorder.lo_partkey = part.p_partkey)
Buffers: shared hit=7778538-> Seq Scan on lineorder (cost=0.00..13759100.40 rows=600061440 width=16) (actual time=0.006..31115.221 rows=600037902 loops=1)
Buffers: shared hit=7758486-> Hash (cost=41051.46..41051.46 rows=3184 width=13) (actual time=636.823..636.824 rows=11270 loops=1)
Buckets: 16384 (originally 4096) Batches: 1 (originally 1) Memory Usage: 657kB
Buffers: shared hit=20052-> Seq Scan on part (cost=0.00..41051.46 rows=3184 width=13) (actual time=0.020..634.619 rows=11270 loops=1)
Filter: (((p_brand1)::text >= 'MFGR#2221'::text) AND ((p_brand1)::text <= 'MFGR#2228'::text))
Rows Removed by Filter: 1388730
Buffers: shared hit=20052-> Hash (cost=26461.59..26461.59 rows=198193 width=4) (actual time=141.636..141.636 rows=199889 loops=1)
Buckets: 262144 Batches: 1 Memory Usage: 9076kB
Buffers: shared hit=13962-> Seq Scan on supplier (cost=0.00..26461.59 rows=198193 width=4) (actual time=0.010..116.053 rows=199889 loops=1)
Filter: ((s_region)::text = 'ASIA'::text)
Rows Removed by Filter: 800111
Buffers: shared hit=13962-> Hash (cost=63.33..63.33 rows=2533 width=8) (actual time=0.592..0.592 rows=2556 loops=1)
Buckets: 4096 Batches: 1 Memory Usage: 132kB
Buffers: shared hit=38-> Seq Scan on date (cost=0.00..63.33 rows=2533 width=8) (actual time=0.008..0.335 rows=2556 loops=1)
Buffers: shared hit=38
Planning Time: 0.197 ms
Execution Time: 94271.519 ms

No .2-2 では、No .1-1 とは異なり、lin eo rder テーブルにおけるシーケンシャルスキャン処理部分に JITコンパイルによるオーバヘッドは発生しておりませんが、代わりに date テー
ブルにおけるシーケンシャルスキャン処理部分に発生しています。 つまり、No .2-2 のクエリにおいてもオーバーヘッドは1 か所のノードでのみ発生していることがわかります。 そして、各テーブルのシーケンシャルスキャンではそれほど高速化していませんが、Hash Jo in ノードにおける処理が高速化されていることがわかります。
6.6.3.3. 削減率が低い原因の考察
削減率が低いクエリについて条件を変更して再検証しました。 具体的には、sh ared_b u ffers パラメータを64G B から 100G B に変更、固定し、w o rk_mem パラメータを
1,2,4G B 、main ten an ce_w o rk_mem パラメータを8,16,32G B と変化させた際に削減率が変わるかを検証しました。

Page 43 of 67

PostgreSQL Enterprise Consortium

図 6.5 JITコンパイルO N/O FF での実行時間
表 6.12 JITコンパイルO N/O FF での実行時間（秒）ク エリ N o.

JIT:OFFJIT:ON

削減率 (% )o rigin al

119.962109.932

8.361

W 1-M8139.948126.646

9.505

W 1-M16141.113127.229

9.839

W 1-M32

142.326

127.772

10.225

W 2-M8140.028

126.374

9.751

W 2-M16142.223127.92210.055

W 2-M32148.642129.573

12.829

W 4-M8123.327

115.550

6.306

W 4-M16126.472

117.974

6.719

W 4-M32130.843

123.784

5.395

結果としては、削減率が向上する場合はあったものの、実行時間が本検証よりも長くなってしまいました。 ここから、パラメータ設定ではなく、クエリの構造を紐解くことで原因がわかるのではないかと考えられます。

6.7. まとめ今回の検証では、JITコンパイルが有効に働くクエリ種を調査するとともに、それによって実行時間がどれだけ削減されるか検証しました。 結果として、四則演算や集約関数へのJITコンパイルの適用は有効であることを示すことができました。 また、テーブルのデータ型によって JITコンパイルによる実行時間の削減率が変化することもわかりました。 そして、SSB クエリを用いた検証では、O LAP 系の大規模な分析クエリへのJITコンパイルを適用することで実行時間を削減することができることを示すことができました。
しかし、クエリの種類によっては削減率が1 割以下に留まるものもありました。
今回はマニュアルに記載がある、JITコンパイルの効果が見込まれる演算、関数のうち、自作の関数について検証は行うことができませんでした。 実際のシステムにおいて、独自に定義した関数は多く使用されているため、今後検証が必要だと思われます。 今回のSSB クエリを用いた検証では、JITコンパイルの効果を見るためにインデックスを

Page 44 of 67

PostgreSQL Enterprise Consortium
設定していません。 実際のシステムではインデックスを設定している場合が多いので、次回の検証ではインデックスを設定した場合において JITコンパイルの効果を検証する必要があると思われます。 また、考察で突き止めることができなかった、削減率が低いクエリの構造を紐解き、削減率が低い原因を解明することも今後行うべきと考えております。 JITコンパイルはPo stgreSQL 11 に実装された新しいものであるため、今後機能の強化などが望まれます。

Page 45 of 67

PostgreSQL Enterprise Consortium

7. パラレルクエリ 性能検証
7.1. 検証概要
近年、ビッグデータ活用の流れから、データベースに大量のデータを投入して検索や集計を行い、新たな知見を得ようとする試みが増えています。 例えば、店舗における売上データなど、経営に関わるデータを組み合わせて多面的に解析するB I(B u sin ess In telligen ce)が典型的です。 このような使用方法においては、長大かつ高負荷となるクエリを処理することとなり、多数の短小なクエリを大量に処理するような使用方法であるO LTP に対して、O LAP と呼ばれています。 一般的に、O LAP ではパラレルクエリやパーティショニングの恩恵を受けやすいとされています。

Po stgreSQL をO LAP 用途で使用したいという要望は、以前から根強くありましたが、Po stgreSQL 9.5 まではパラレルクエリが実装されていなかったため、O LAP 用途で実用的に使用できない状態でした。
そこで、Po stgreSQL 9.6 で実装され、Po stgreSQL 10 以降で継続して強化されているパラレルクエリによって、Po stgreSQL がO LAP 用途で実用的に使用できるようになったのかを検証します。 本検証では、O LAP において使用される形式のクエリを模したベンチマークテストであるStar Sch ema B en ch mark で定義されているクエリを題材として使用します。

7.1.1. Star Schema BenchmarkとはStar Sch ema B en ch mark とは、 Star Sch ema B en ch mark の論文 によって公表されている、TPC-H をもとに B I で用いられるものを模したファクトテーブル、ディメンジョン
テーブル、クエリが設計されているベンチマークツールです。
大規模なデータを取り扱うので、I/O 周りはもちろんのこと、多数のジョイン操作や集約演算が行われることから、通常のO LTP よりもCPU の処理性能と、CPU をどの程度うまく使えているかがベンチマーク結果を大きく左右します。

Star Sch ema B en ch mark では、4 種類/13 本のクエリが定義されており、そのすべてについて検証を行いました。

7.2. パラレルクエリとは
7.2.1. パラレル クエリ
パラレルクエリとは、一つのクエリを複数のプロセスで分担して並列処理することで、単一プロセスでの処理よりも高速にクエリを実行する処理方式です。
例えばSELECT文で1000 万レコードを全件検索する場合、検索で使用するプロセスが1 個だけだと1 プロセスが1000 万レコードをすべて検索する必要があります。 それに対して、例えば、検索で使用するプロセスが10 プロセスあって、それらで分担することができれば、1 プロセス当たりの検索対象は100 万レコードと10 分の1 に減ります。 複数のプロセスで分担することで高速化を図るため、メニーコア環境での使用で、効果を発揮します。
複数のプロセスで検索処理を分担して実行することで、1 プロセスあたりの検索自体にかかる実行時間は短くなりますが、ある処理を複数に分割する配分の制御や受け渡し、そして複数で処理した結果を集めて一つにまとめる処理などの実行時間が長くなります。 複数のプロセスで短縮できる時間があまり少ないと、パラレルクエリに変更する
ことでむしろ余計に実行時間がかかってしまうこともあります。
そのため、プランナは多くの実行プランの中から、パラレルクエリのほうが効率的に処理できると判断した場合のみパラレルクエリの実行プランを選択します。

7.2.2. PostgreSQL で の パラレル クエリ
2018 年現在、Po stgreSQL で実装されているパラレルクエリに関する処理は、パラレルスキャン、パラレルジョイン、パラレル集約、B -Tree インデックス作成の四種類です。
前者三種類については、プランナが処理を分担したほうが効率的だと判断した場合、パラレルクエリのプランを採用します。

exp lain (an alyze , verb o se)で確認したパラレルクエリ プラン例QUERY PLAN--------------------------------------------------------------------------------------------------------------------------------------Gather (cost=1000.00..112816.10 rows=38400 width=52) (actual time=0.198..224.017 rows=99740 loops=1)
Output: log_id, date, "time", product_id, place_id, machine_id, app_id, access_time_second, access_count, err_code
Workers Planned: 4Workers Launched: 4-> Parallel Seq Scan on public.access_log (cost=0.00..107976.10 rows=9600 width=52) (actual time=0.017..209.797 rows=19948 loops=5)
Output: log_id, date, "time", product_id, place_id, machine_id, app_id, access_time_second, access_count, err_code
Filter: ((access_log.log_id % '77'::bigint) = 0)
Rows Removed by Filter: 1516052
Worker 0: actual time=0.016..214.828 rows=20088 loops=1
Worker 1: actual time=0.016..214.518 rows=19967 loops=1
Worker 2: actual time=0.020..218.061 rows=20817 loops=1
Worker 3: actual time=0.015..213.654 rows=20054 loops=1
パラレルクエリでは、親プロセスに加えワーカーがバックグラウンドワーカープロセスとして起動されて処理を実行するため、検索プロセス数は親プロセスとワーカーの合計となりま

Page 46 of 67

PostgreSQL Enterprise Consortium
す。そして、各プロセスで処理した結果をG ath er ノードで集約します。
また、パラレルクエリで起動されるワーカー数は、テーブルサイズによりデフォルトで起動する数が決まっています。
表 7.1 テーブルサイズによるワーカー数
ブロ ック 数 [1]

サイ ズ（ M B ）起動ワーカ ー数

検索プロ セス数

1,024

8

1

2

3,072

24

2

3

9,216

72

3

4

27,648216

4

582,944648

5

6248,832

1,944

6

7

746,496

5,832

7

8

2,239,488

17,4968

96,718,464

52,4889

1020,155,392

157,464

10

11

・・・

・・・

・・・

・・・

[1] プロック数はブロックサイズがデフォルト(8KB )の場合です。

7.2.3. パラレル クエリ に関連するパラメー タ
パラレルクエリ時に関連する主なパラメータには以下のパラメータがあります。なお、max_p arallel_w o rkers_p er_gath er パラメータのデフォルト値がバージョン9.6 では0 のため、デフォルト設定ではパラレルクエリは実行されません。バージョン10 以降では同パラメータのデフォルト値は2 であるため、デフォルト設定でもパラレルクエリが実行されます。

表 7.2 パラレルクエリに関連する主なパラメータパラ メ ータ

デフォルト 値 (9.6)

デフォルト 値 (10)デフォルト 値 (11)説明

max_w o rker_p ro cesses [2]

8

8

8

システムがサポートするバックグラウンドワーカープロセスの最大数を指定します。

max_p arallel_w o rkers_p er_gath er
[2]

0

2

2

一つのG ath er ノードに対して起動できるワーカー数の最大値を指定します。

max_p arallel_w o rkers [2] [3]

―

8

8

一度に有効となるパラレル
ワーカープロセスの最大数を指定します。

max_p arallel_main ten an ce_w o rkers ―
[4]

―

2

メンテナンス一回につき有効となるパラレルワーカープロセ
スの最大数を指定します。

min _p arallel_relatio n _size

8MB

―

―

パラレル処理を行うテーブルの最小サイズを指定します。

min _p arallel_tab le_scan _size

―

8MB

8MB

パラレル処理を行うテーブルの最小サイズを指定します。

min _p arallel_in dex_scan _size

―

512KB

512KB

パラレル処理を行うインデック
スの最小サイズを指定します。

p arallel_setu p _co st

1000

1000

1000

ワーカーを起動するためのコストに対するプランナの推測値を指定します。

p arallel_tu p le_co st

0.1

0.1

0.1

あるワーカーから、1 行を他のプロセスに転送するためのコストに対するプランナの推測値を指定します。

[2] (1, 2, 3) max_p arallel_w o rkers_p er_gath er で指定した値がmax_w o rker_p ro cesses で指定した値を超える場合、起動されるワーカー数は
max_w o rker_p ro cesses の値に制限されます。また、複数のパラレルクエリが同時に行われる場合、起動されるワーカー数の合計がmax_w o rker_p ro cesses で指定した値に制限されます。このため、プラン作成時のワーカー数よりも実際に起動されるワーカー数が少ない場合があります。

Page 47 of 67

PostgreSQL Enterprise Consortium[3] Po stgreSQL 10 以降では、max_p arallel_w o rkers もあり、パラレルクエリの実行に使用されるワーカー数は、基本的にはこちらに指定した値に制限されます。ただし、この値がmax_w o rker_p ro cesses で指定した値を超える場合は、起動されるワーカー数はmax_w o rker_p ro cesses の値に制限されます。
[4] Po stgreSQL 11 で追加されました。max_p arallel_main ten an ce_w o rkers で指定した値がmax_w o rker_p ro cesses で指定した値を超える場合、起動されるワーカー数はmax_w o rker_p ro cesses の値に制限されます。また、パラレルクエリ等が同時に実行されている場合、起動されるワーカー数の合計がmax_w o rker_p ro cesses で指定した値に制限されます。このため、プラン作成時のワーカー数よりも実際に起動されるワーカー数が少ない場合があります。

7.3. 検証構成
7.3.1. 検証ハー ドウ ェア構成
検証環境のハードウェア構成の概略を示します。
本パラレルクエリ検証ではDB サーバ上でSQL を直接実行する形式としました。 検証では下記構成の「 DB サーバ#2 」を使用しました。

図 7.1 検証ハードウェア構成

Page 48 of 67

PostgreSQL Enterprise Consortium
表 7.3 検証用DB サーバ構成
機器
検証サーバ (DL380 G en 10)

項目

仕様

CPU

インテル Xeo n G o ld 6142@ 2.60G Hz
16 コアx2 合計 32 コア
ハイパースレッディング:o ff

搭載メモリ

384G B

外付けストレージ装置 (3PAR

HDD 1.8TB SAS 10K x 24

8200)

7.3.2. 検証ソフトウ ェア構成
検証環境のソフトウェア構成を示します。
表 7.4 ソフトウェア構成
種類

OS

ソフト ウェ ア名およびバージョ ン

Red Hat En terp rise Lin u x 7.5

Datab ase Po stgreSQL 9.5.15
Po stgreSQL 9.6.11
Po stgreSQL 10.6
Po stgreSQL 11.1

7.4. 検証方法
7.4.1. 検証項目
パラレルクエリ検証では以下の3 点を検証します。

7.4.1.1. 検証 A
検証A では、p o stgresql.co n f で、デフォルトではコメントアウトされているパラレルクエリ関連のパラメータのコメントアウトを単に外した (有効化した )だけの状態で、パラレル
クエリでの処理性能の改善状況を確認します。
本検証によって、単にパラレルクエリを有効化した状態で、O LAP 用途におけるクエリに対する性能が、どの程度改善するのか、もしくは悪化するのかを明らかにします。 これにより、コメントアウトを外すだけという簡単な作業のみで、クエリに対する応答性能がどのように変動するのかが明らかになります。 (特に、バージョン10 、バージョン11 においては、デフォルトの設定そのものの性能を検証することになります。)
また、比較対象として、パラレルクエリが実装される前のバージョン9.5 での性能も検証することで、9.5 〜11 の各バージョンのデフォルト設定のままで、O LAP 用途におけるクエ
リに対する性能が、どのように変化するのかを明らかにします。

7.4.1.2. 検証 B
検証B では、パラレルクエリの並列度による処理性能の改善状況を確認します。
検証A におけるパラメータに加えて、max_w o rker_p ro cesses 、max_p arallel_w o rkers_p er_gath er 、max_p arallel_w o rkers(バージョン10 以降)の各パラメータの値を変更し、並列度の違いによる処理時間を比較します。
本検証によって、パラレルクエリ関連パラメータ、特に並列度のチューニングによって、O LAP 用途におけるクエリに対する性能が、検証A との比較でさらに改善する余地があるのかどうかを明らかにします。

7.4.1.3. 検証 C
検証C では、バージョン11 において新たに追加された、B -Tree インデックスのパラレル作成について、並列度による処理性能の改善状況を確認します。

max_w o rker_p ro cesses 、max_p arallel_main ten an ce_w o rkers の各パラメータの値を変更し、並列度の違いによる処理時間を比較します。
本検証によって、パラレルクエリ関連パラメータ、特に並列度のチューニングによって、B -Tree インデックスの作成時間が、どの程度改善する余地があるのかを明らかにします。

7.4.1.4. 対照群
対照群として、バージョン9.6 、バージョン10 、バージョン11 において、max_p arallel_w o rkers_p er_gath er= 0 に明示的に設定を行った状態で 処理時間を比較します。
これにより、検証A 、検証B において、パラレルクエリ部分によらない性能改善がどの程度あったのかを明らかにします。

7.4.2. デ ー タモデ ルPage 49 of 67

PostgreSQL Enterprise Consortium
本検証で使用するデータモデルは、Star Sch ema B en ch mark において定義されているデータモデルに準拠します。

Scale Facto r は100G B を採用しました。各テーブルのサイズは、以下のとおりです。
relname | rows|
bytes-----------+-----------+------------part| 1400000 | 164265984
supplier | 1000000 | 114376704
customer | 2999990 | 374030336
date|
2556 |
311296
lineorder | 600113000 | 63557664768

7.4.3. 使用クエリ につい て
本検証では、Star Sch ema B en ch mark で定義される全クエリを使用します。
これは Star Sch ema B en ch mark の論文 の"3.1 Qu ery Defin itio n "に掲載されているものであり、 JITコンパイル 性能検証 で使用したものと同一です。

7.4.4. DB設定
性能測定にあたり、デフォルトから変更したパラメータは以下のとおりです。
表 7.5 デフォルトから変更したパラメータパラ メ ータ

検証サーバ 1

listen _addresses*

sh ared_b u ffers

150G Bw o rk_mem

1G B

main ten an ce_w o rk_mem

20G B

au to vacu u mo ff

max_w o rker_p ro cesses [5]8max_p arallel_w o rkers_p er_gath er [5]2

max_p arallel_w o rkers [5] [6]8max_p arallel_main ten an ce_w o rkers [5] [7] 2
lo g_lin e_p refix'%t [%p -%l]: '[5] (1, 2, 3, 4) 測定により値を変更して実施します。
[6] Po stgreSQL 10 以降[7] Po stgreSQL 11 のみ

7.4.5. 測定手順
測定に際しては、SQL の実行前に p g_p rew arm を利用して、テーブル・インデックスのデータをディスクから一度読み込み、Po stgreSQL のバッファ上、もしくはO S のディスク
バッファ上に常駐させた状態にします。

SELECT relname, pg_prewarm(oid)
FROM pg_class
WHERE relnamespace in (SELECT oid
FROM pg_namespace
WHERE nspname='public') AND (
relkind='r' OR relkind='i');
7.4.5.1. 検証 A 測定方法
Star Sch ema B en ch mark で定義される全クエリを、p sql を用いて実行します。
7.4.5.2. 検証 B 測定方法
Star Sch ema B en ch mark で定義される全クエリを、p sql を用いて実行します。

Page 50 of 67

PostgreSQL Enterprise Consortium
測定に際しては、p o stgresql.co n f に以下の設定を行い、再起動を行うことで設定の反映を行っています。 また、測定を行う前にはp g_p rew arm を用いて、メモリ上にデータを常駐させた状態にしています。
表 7.6 検証時設定

パラ メ ータgather gather gather gather gather
= 2,
= 2,
= 4,
= 4,
= 6,
workers workers workers workers workers= 2 [8] = 8 [9] = 4 [8] = 16 [9] = 6 [8]gather= 6,
workers= 24 [9]gather= 8,
workers= 8 [8]gather= 8,
workers= 32 [9]gather= 10,
workers= 10 [8]gather= 10,
workers= 40 [9]max_p arallel_w o rkers_p er_geth er 2

2

4

4

6

6

8

8

10

10

max_w o rker_p ro cesses

2

8

4

16

6

24

8

32

10

40

max_p arallel_w o rkers

2

8

4

16

6

24

8

32

10

40

[8] (1, 2, 3, 4, 5) w o rkers の値がgath er の値と同値であるパターンで、以下w o rker= gath er と表記します。
[9] (1, 2, 3, 4, 5) w o rkers の値がgath er の値の4 倍であるパターンで、以下w o rker= gath er*4 と表記します。
7.4.5.3. 検証 C 測定方法
Star Sch ema B en ch mark で定義されるlin eo rder テーブルに対し、以下の列を対象として B -Tree インデックスを作成します。
表 7.7 複合インデックスの作成
対象列
複合数

対象列

1

lo _o rderkey

2

lo _o rderkey
lo _cu stkey3

lo _o rderkey
lo _cu stkey
lo _p artkey4

lo _o rderkey
lo _cu stkey
lo _p artkey
lo _su p p key

測定に際しては、p o stgresql.co n f に以下の設定を行い、再起動を行うことで設定の反映を行っています。 また、測定を行う前にはp g_p rew arm を用いて、メモリ上にデータを常駐させた状態にし、測定後はDRO P INDEXによって、インデックス削除しています。
表 7.8 検証時設定
パラ メ ータ

workers = 0

max_p arallel_main ten an ce_w o rkers 0

workers = 2
2

workers = 4
4workers = 6
6workers = 887.5. 検証結果
7.5.1. 検証 A(パラレル クエリ を有効にしたことによる効果 )表 7.9 検証条件
スト レージ外付ストレージ装置

SQL 文

保持データ 量Star Sch ema B en ch mark で定義される全クエリ Scale Facto r = 100G B

上記の条件で検証を行った結果、バージョン9.6 以降では、全クエリでパラレルクエリが動作しました。
バージョン毎の処理時間のグラフと表を以下に示します。

Page 51 of 67

workers = 10
10

PostgreSQL Enterprise Consortium

図 7.2 バージョンと処理時間の比較

表 7.10 バージョンと処理時間

9.6 処理時間(秒 )9.6 性能向上比( 倍 ) [10]q1.1

109.6738

43.0780

2.545938.59222.841936.0279

3.0441q1.2

100.5875

40.4387

2.487436.41372.762434.01072.9575q1.3

99.071940.2400

2.462036.44192.718634.09672.9056q2.1

153.6779

61.27172.508157.8688

2.655658.23292.6390q2.2

127.4209

51.75032.462250.4701

2.524747.1534

2.7023q2.3

106.7450

46.5650

2.292446.3889

2.301141.9794

2.5428q3.1

229.1734

79.8066

2.871675.15543.049388.37122.5933q3.2

143.0648

58.9300

2.427753.40462.678949.8938

2.8674q3.3

127.0212

50.50202.515250.1682

2.531948.04442.6438q3.4

128.4246

51.47372.495051.7527

2.481548.21422.6636q4.1

232.5540

99.31212.341695.90632.424872.7343

3.1973q4.2

232.1840

97.3383

2.385394.58222.454872.4182

3.2062q4.3

144.7047

58.06622.492155.04902.628756.3806

2.5666ク エリ

10 処理時間(秒 )10 性能向上比( 倍 ) [10]11 処理時間(秒 )11 性能向上比 ( 倍 )[10]

9.5 処理時間(秒 )[10] (1, 2, 3) 性能向上比は、バージョン9.5 の結果を、比較対象の各バージョンでの結果で除したものです。以下の性能向上比も、すべてこの方法で計算しています。
検証の結果、クエリの処理時間について、バージョン9.5 との比較で、バージョン9.6 で2.34 倍(q4.1)～2.87 倍(q3.1)、バージョン10 で2.42 倍(q4.1)～3.04 倍(q3.1)、バー

Page 52 of 67

PostgreSQL Enterprise Consortium
ジョン11 で2.54 倍(q2.3)～3.20 倍(q4.2)の高速化が認められました。

7.5.2. 検証 B(並列処理数 (起動するワー カー の 数 )の 違い による検証結果 )図 7.3 max_p arallel_w o rkers の値と処理時間の比較 (バージョン10 / w o rkers = gath er)

表 7.11 並列処理数と処理時間 (バージョン10 / w o rkers = gath er)
ク エリ

0

2

4

6

8

10

q1.1

85.4489

56.9939

30.2153

20.6437

16.2143

13.1179

q1.2

82.9543

53.594428.503919.8002

15.2736

12.4638

q1.3

82.840353.5943

28.5369

19.8255

15.2616

12.3869

q2.1

150.0331 83.3708

44.1458

31.4149

25.0433

21.8037q2.2

135.3275 76.3389

39.401226.8608

20.8826

17.0109q2.3

105.8896 68.9048

36.32825.090119.72616.0949

q3.1

197.5059 106.1948 56.3073

39.1798

30.680928.5272

q3.2

142.1985 76.8667

41.6347

29.201622.7531

19.2159

q3.3

125.7963 73.8228

38.8993

26.8994

20.8419

17.1459

q3.4

129.0627 76.5403

40.231527.5024

21.0395

16.859q4.1

226.6286 124.6846 67.0518

48.409638.2259

38.2996q4.2

222.4871 124.4402 67.2911

48.113437.925237.0782

q4.3

138.6454 77.0612

29.6051

23.37

19.7866

42.2118

Page 53 of 67

PostgreSQL Enterprise Consortium

図 7.4 max_p arallel_w o rkers の値と処理時間の比較 (バージョン10 / w o rkers = gath er*4)

表 7.12 並列処理数と処理時間 (バージョン10 / w o rkers = gath er*4)
ク エリ

0

2

4

6

8

10

q1.1

85.4489

38.592224.4377

18.1406

12.610913.1812q1.2

82.9543

36.4137

23.03417.1541

11.8751

12.5499

q1.3

82.840336.441923.072117.1504

11.8915

12.5125q2.1

150.0331 57.8688

38.091230.421121.7118

21.9554q2.2

135.3275 50.4701

32.34924.4605

18.0272

17.1562q2.3

105.8896 46.3889

29.0172

22.361715.7164

15.9769

q3.1

197.5059 75.1554

48.358736.2399

28.8156

28.4356

q3.2

142.1985 53.4046

34.6972

26.9351

20.1988

19.3084

q3.3

125.7963 50.1682

31.2504

23.6949

17.65417.156q3.4

129.0627 51.7527

31.9982

24.0661

17.621416.8232q4.1

226.6286 95.9063

58.326144.51

39.2568

38.3434

q4.2

222.4871 94.5822

57.602944.0192

37.973737.281q4.3

138.6454 55.049

36.3353

27.9577

19.7588

20.0958

Page 54 of 67

PostgreSQL Enterprise Consortium

図 7.5 max_p arallel_w o rkers の値と処理時間の比較 (バージョン11 / w o rkers = gath er)

表 7.13 並列処理数と処理時間 (バージョン11 / w o rkers = gath er)
ク エリ

0

2

4

6

8

10

q1.1

84.764753.656229.0181

19.9105

15.3618

12.5352

q1.2

81.641450.5466

27.3301

18.8776

14.4657

11.8407

q1.3

80.5189

50.3723

27.4255

18.8421

14.5301

11.8443q2.1

141.5359 85.4431

45.13631.1805

23.6265

19.3543q2.2

126.01669.463637.0795

26.1183

19.2126

15.5833

q2.3

102.9223 61.1581

33.834322.9064

17.549314.3799

q3.1

209.2735 130.4551 54.3009

37.434228.645423.2988q3.2

128.2047 72.8591

39.27126.7486

20.5554

16.4219q3.3

120.6891 70.5463

35.8179

24.273118.64114.9511q3.4

120.2251 69.9018

36.268324.329418.4329

15.19

q4.1

247.059106.2362 55.7347

38.3949

29.6088

23.8907

q4.2

187.3207 106.0171 55.2027

38.0867

29.1774

23.5996q4.3

135.0164 82.7183

35.4254

35.5206

36.083943.2652

Page 55 of 67

PostgreSQL Enterprise Consortium

図 7.6 max_p arallel_w o rkers の値と処理時間の比較 (バージョン11 / w o rkers = gath er*4)

表 7.14 並列処理数と処理時間 (バージョン11 / w o rkers = gath er*4)
ク エリ

0

2

4

6

8

10

q1.1

84.7647

36.0279

23.3482

17.382312.0182

12.4706

q1.2

81.641434.0107

22.09316.3843

11.3385

12.0085q1.3

80.5189

34.0967

22.0687

16.540311.3078

11.7771

q2.1

141.5359 58.2329

37.08827.7059

19.7786

19.0712q2.2

126.016

47.1534

30.1746

21.9779

16.0026

15.4808

q2.3

102.9223 41.9794

27.2528

20.0144

14.33514.2886

q3.1

209.2735 88.3712

45.2504

33.0227

23.5292

23.3375q3.2

128.2047 49.8938

31.8979

23.5351

16.5862

16.5175q3.3

120.6891 48.0444

28.6483

21.2713

15.1452

15.001q3.4

120.2251 48.2142

28.8943

21.1918

14.9976

15.0031q4.1

247.05972.734345.9153

33.6155

24.29523.8475

q4.2

187.3207 72.4182

45.583733.3028

24.0262

23.658q4.3

135.0164 56.3806

35.6238

36.23332.908535.7456

検証の結果、全クエリが、並列処理数の増加にともなって、処理時間が減少する傾向にありました。 グラフの形状からは、処理時間と並列処理数の間には、反比例に近い関係があると推測できます。
また、w o rkers = gath er とw o rkers = gath er*4 を比較すると、バージョン10 とバージョン11 では、並列処理数が2 から 8 の間では、gath er*4 の方が高速である傾向が確認できました。

Page 56 of 67

PostgreSQL Enterprise Consortium
ただ、バージョン11 のq4.3 は、並列処理数4 以上の性能が頭打ちとなっており、バージョン11 特有の問題が発生している可能性があります。

7.5.3. 検証 C

図 7.7 max_p arallel_main ten an ce_w o rkers の値と処理時間の比較

表 7.15 並列処理数と処理時間
ワーカ ー数

1列 (秒 )

2列 (秒 )

3列 (秒 )

4列 (秒 )

0318.9848

335.4180

422.8608

433.40362

196.6795

201.9619

254.7677

254.71214

154.8794

156.7898

201.9349

202.06196

136.3506

137.5311

181.1933

183.17368

123.7943

127.3894

159.4948

166.3534

10

123.2796

123.4265154.0125156.4379

検証の結果、並列処理数の増加にともなって、処理時間が減少する傾向にありました。 グラフの形状からは、処理時間と並列処理数の間には、反比例に近い関係があると推測できます。

7.5.4. 対照群 (パラレル クエリ off)

Page 57 of 67

PostgreSQL Enterprise Consortium

図 7.8 バージョンと処理時間の比較

表 7.16 バージョンと処理時間
9.6 性能向上比
10 処理時間(倍 )(秒 )10 性能向上比(倍 )107.8582

1.016885.4489

1.283584.7647

1.2939100.5875

105.0022

0.958082.9543

1.212681.64141.2321q1.3

99.0719101.5858

0.975382.8403

1.195980.51891.2304q2.1

153.6779

168.0892

0.9143150.0331

1.0243141.5359

1.0858q2.2

127.4209147.6302

0.8631135.3275

0.9416126.0160

1.0111q2.3

106.7450

122.7834

0.8694105.8896

1.0081102.9223

1.0371

q3.1

229.1734

215.4955

1.0635

197.5059

1.1603209.2735

1.0951

q3.2

143.0648

159.3785

0.8976142.1985

1.0061128.2047

1.1159q3.3

127.0212138.7790

0.9153125.7963

1.0097120.6891

1.0525q3.4

128.4246134.3616

0.9558129.0627

0.9951120.2251

1.0682q4.1

232.5540

248.7920

0.9347226.6286

1.0261247.0590

0.9413q4.2

232.1840

238.1739

0.9749222.4871

1.0436187.3207

1.2395q4.3

144.7047

162.9800

0.8879138.6454

1.0437135.0164

1.07189.5 処理時間(秒 )9.6 処理時間
(秒 )

q1.1

109.6738

q1.2

ク エリ

11 処理時間(秒 )11 性能向上比 ( 倍 )検証の結果、クエリの処理時間について、パラレルクエリo ff の状態で、バージョン9.5 との比較でバージョン9.6 では0.91 倍(q2.1)～1.01 倍(q1.1)、バージョン10 では0.94 倍(q2.2)～1.21 倍(q1.2)、バージョン11 では0.94 倍(q4.1)～1.29 倍(q1.1)の高速化が認められました。
ここから、パラレルクエリ以外の部分でバージョン9.6 とバージョン10 、バージョン10 とバージョン11 の間において改善が行われ、大部分が高速化したことが伺えます。

Page 58 of 67

PostgreSQL Enterprise Consortium

7.6. 考察7.6.1. 検証 A
検証A では、パラレルクエリのないバージョン9.5 よりバージョン9.6 の方が高速であり、バージョン9.6 よりもバージョン10 、バージョン11 の方が概ね高速である傾向が見られました。 ただし、バージョン10 とバージョン11 の間の差は、概ねバージョン11 の方が高速であるものの、q3.1 ではバージョン10 が最も早く、q4.1 とq4.2 ではバージョン11 が大幅に高速でした。

q3.1 では、バージョン10 とバージョン11 で結合順が変化しており、これが原因となってバージョン11 で速度が低下した可能性があります。
q4.1 とq4.2 では結合順は変化しておらず、ディメンジョンテーブルであるp art, su p p lier, date の各テーブルのSeqScan に要する時間が、バージョン10 と比較して 1/3 となっていることが確認できました。
パラレルクエリでのJo in ノードにおける右側(In n er)のテーブルの検索処理は、バージョン10 までは各パラレルワーカーがそれぞれのテーブルを全検索する関係で、検索時間が各パラレルワーカーでの所要時間分だけ増加していました。 バージョン11 での高速化は、新機能であるハッシュテーブルの共有化により、テーブルスキャンが1 回になった結果であると考えます。 SSB でのディメンジョンテーブルは、テーブルサイズが数百MB となるものもあるため、ハッシュテーブルの共有化によるスキャン回数低減が大きな効果をもたらしたものと言えます。
以上から、バージョン11 からの新機能であるハッシュテーブルの共有化は、複数のテーブルの結合操作時に、テーブルの大きさが大きいほど効果が出やすいと考えます。
なお、2016 年度のパラレルクエリ検証 で使用した検証用クエリを使用しての検証も行いましたが、 こちらの結果 からはバージョン10 とバージョン11 の間の差はほとんどなく、
この2 バージョンのパラレルクエリの基本性能は互角と言って差し支えないと考えます。

7.6.2. 検証 B

7.6.2.1. max_worker_processes 、 max_parallel_workers 、 max_parallel_workers_per_gather 間の関係
バージョン10 とバージョン11 では、ほとんどのクエリで max_w o rker_p ro cesses 、max_p arallel_w o rkers を max_p arallel_w o rkers_p er_gath er の4 倍の値としたパターンの方が、max_w o rker_p ro cesses 、max_p arallel_w o rkers と max_p arallel_w o rkers_p er_gath er を同値とした場合よりも高速に動作しました。 以下に、
SSB q3.1 におけるw o rkers = 0 (パラレルクエリなし) と 特に顕著な差を認めた w o rkers = 2 (起動予定ワーカー数2) の性能向上比を示します。
表 7.17 SSB q3.1 におけるパターンと性能向上比
workers=0
workers=2

パタ ーン

性能向上比 ( 倍 )バージョン10 w o rkers = gath er

197.5059

106.1948

1.8598バージョン11 w o rkers = gath er

209.2735

130.4551

1.6042

バージョン10 w o rkers = gath er*4

197.5059

75.15542.6280バージョン11 w o rkers = gath er*4

209.2735

88.37122.3681

誤差とは言えない大きさの差がついているため起動ワーカー数が正しくないのではないか、との仮説を立て、SSB q3.1 のw o rkers = 2 を対象に、EXPLAIN ANALYZE 中の起動ワーカー数を確認しました。 その確認結果を以下に示します。
表 7.18 バージョンと起動ワーカー数
バージョ ン

workers = gather

workers = gather*4

10

1

2

11

1

2

実際の並列度は起動ワーカー数+ 1 であるため、w o rkers = gath er のパターンでは並列度2 、w o rkers = gath er*4 のパターンでは並列度3 となります。 パターンと性能向上比の関係が、並列度とほぼ一致していることがわかります。
これは、バージョン10 以降では、パラレルクエリのためのワーカーとは別に、バックグラウンドワーカーが1 つ起動していることを示唆します。 このため、
max_w o rker_p ro cesses の上限に達してしまい、パラレルクエリ用に起動予定のワーカーを一部立ち上げられなかったものと推測します。
バージョン10 以降のバックグラウンドワーカーは、パラレルクエリ以外にはロジカルレプリケーション用のものが挙げられます。 パラレルクエリ関連のパラメータ設定を行うにあたっては、他にバックグラウンドワーカーを使用する(パラレルクエリの動作と競合する)機能との整合を十分に考慮する必要があると考えます。

7.6.2.2. バージョ ン 11 に おける SSB q4.3 の性能

Page 59 of 67

PostgreSQL Enterprise Consortium
バージョン11 において、SSB のq4.3 の性能が並列処理数4 で頭打ちとなりました。
バージョン9.6 とバージョン10 ではこの現象は起きておらず、バージョン11 固有の現象であることがわかります。 今回の検証で使用したテーブルのサイズからは、並列処理数の理論値は9 であるため、並列処理数9 付近まで性能が改善することを予想していました。
そこで、実行計画上の並列処理数を確認しました。その結果を以下に示します。 実行計画上の並列処理数は、パラレルクエリ使用時に現れる G ath er ノード内の"W o rkers Plan n ed"の値として、EXPLAIN の実行結果内に示されます。
表 7.19 SSB q4.3 における並列処理数の設定と実行計画での値
max_parallel_workers_per_gather
Workers Planned

0

―

2

2

4

4

6

4

8

4

10

4

以上から、実行計画として並列処理数が4 より大きい値にならないことがわかりました。 次に、現象が発生していないバージョン10 と現象が発生するバージョン11 の実行計
画を比較します図 7.9 Star Sch ema B en ch mark q4.3 の実行計画(バージョン10)

Page 60 of 67

PostgreSQL Enterprise Consortium

図 7.10 Star Sch ema B en ch mark q4.3 の実行計画(バージョン11)

バージョン10 とバージョン11 の間で、実行計画の形が変化していることがわかります。 ここで、各テーブルの物理サイズと起動予定ワーカー数を調べました。
表 7.20 SSB テーブル(SF= 100G B )におけるテーブルサイズと起動予定ワーカー
数
テーブル名

テーブルの物理サイ ズ

起動予定ワーカ ー数

lin eo rder

59 G B

9

cu sto mer

357 MB4date

336 kB0su p p lier

109 MB3p art

157 MB

3

上記の中で、起動予定ワーカー数が9 となるのは lin eo rder テーブルのみであり、一方で起動予定ワーカー数が4 となるのは cu sto mer テーブルのみです。 ここで、上記のバージョン11 の実行計画を確認すると、バージョン11 の実行計画は、最上位にあるのHash Jo in の左側(O u ter)に cu sto mer テーブルのSeqScan が存在します。[11] 一
方で、問題が発生していないバージョン10 の実行計画では、lin eo rder テーブルのSeqScan が最上位のHash Jo in の左側(O u ter)から、左に辿っていった末端に存在します。

[11] 実行計画を出力するツールの制限でパラレルクエリ関連の情報が出力されていませんが、上記バージョン11 の実行計画中のSeqScan 、Hash Jo in はそれぞれ
Parallel Seq Scan 、Parallel Hash Jo in です。
このため、このクエリ全体の起動予定ワーカー数を決定するものは、最上位のJo in ノードにおける左側(O u ter)側の起動予定ワーカー数ではないか、という仮説を立て、バージョン11 のソースコードを確認しました。 この結果、実行計画の最適化機構(O p timizer)内の結合方法を検討する部分のコードに、以下のコードがあることを確認しました。

/* This is a foolish way to estimate parallel_workers, but for now... */pathnode->jpath.path.parallel_workers = outer_path->parallel_workers;
以上のコードがもととなり、クエリ全体の起動予定ワーカー数が cu sto mer テーブル由来の起動予定ワーカー数で規定されたものと考えます。 なお、このコードはバージョン
9.6 から存在しており、本件と同様の問題が、バージョン9.6 以降のすべてのバージョンで起こりうると考えます。
本件については、Po stgreSQL の開発コミュニティに報告の上、ロジックが改良されるよう働きかけていきます。

7.6.3. 検証 C
B -Tree インデックスをパラレルで作成する処理において、複合インデックスの対象列が3 以上となった場合に、2 以下の場合と比較して、およそ1.25 倍〜1.35 倍の時間がかPage 61 of 67

PostgreSQL Enterprise Consortium
かるようになりました。
インデックスの作成は、作成対象のテーブルにアクセスする必要があるため、対象列の増加に伴って処理量が増えたためであると想定しました。 この場合、対象列と作成時間の差に関して、比例の関係となることになります。 そこで、対象列と作成時間の差を比較しました。結果を以下に示します。
表 7.21 CREATE INDEXにおける複合列数と対象列数1 との差
ワーカ ー数

列数 2 と 列数 1 の差分

列数 3 と 列数 1 の差分

列数 4 と 列数 1 の差分

016.4333

103.876

114.4189

2

5.282458.0882

58.03264

1.910447.0555

47.18256

1.180544.842746.8238

3.595135.700542.5591100.146930.732933.1583以上から、対象列1 と対象列2 、対象列3 と対象列4 で、作成時間にほとんど差が見られず、比例関係にはないことがわかり、したがって、対象列数の増加に伴うものではないことがわかります。
作成時間に影響を与える要因としては、TO ASTへのアクセスが発生する場合です。 TO ASTではデータ圧縮されている他、テーブルデータの一部のみがTO ASTに配置される場合もあり、この場合TO ASTアクセスに伴うオーバヘッドが発生します。 しかし、TO ASTにデータが配置されるのは、テーブルの1 行のサイズが 1 物理ページ(デフォルト
8kB )を 超える場合のみであり、今回の lin eo rder テーブルは、1 行が94B にとどまっているため、当てはまりません。
他の要因としては、インデックスのサイズが大きくなる場合です。 B -Tree インデックスの大きさは、複合列にまたがるインデックスの場合、各列に格納されている値の一意な組
み合わせの数に依存します。 そこで、今回検証した列の組み合わせにおいて、組み合わせ数を算出しました。
表 7.22 複合インデックスの対象列と組み合わせ数
複合数

対象列

組み 合わせ数1

lo _o rderkey

150000000

2

lo _o rderkey
lo _cu stkey

150000000

3

lo _o rderkey
lo _cu stkey
lo _p artkey

600036916

4

lo _o rderkey
lo _cu stkey
lo _p artkey
lo _su p p key

600038145以上から、複合インデックスの対象列が1 の場合と2 の場合の間で組み合わせ数が変わっておらず、2 の場合と3 の場合の間で大幅に増加、3 の場合と4 の場合の間で微増にとどまっていることがわかります。
これは、列数2 以上の各複合インデックス作成時間と列数1 のインデックス作成時間の差の傾向と一致します。 ここから、対象列数が3 以上となった場合にインデックス作
成時間が増加したのは、対象列における一意な組み合わせの数が増加したことによるものと考えます。

7.7. 総括
Po stgreSQL 9.6 においてパラレルクエリが実装されたことによって、大規模エンタープライズ用途向けの機能の一つがPo stgreSQL に新たに加わり、Po stgreSQL は新たな時代に突入したと感じていました。 実際に検証を行った結果、昨年度と比較して、注意点は依然として多いもののパラレルクエリは実用に耐えうるものになったと思います。
特に、テーブルの検索やテーブルの結合、ソート、集約演算といった基本操作のパラレル対応はもちろんのこと、大きいテーブルの結合操作に効果を発揮するハッシュテーブ
ルの共有化といった新機能で、大量のデータ内から目的の情報を探索・導出するといった作業を効率的に行えるようになったものと確信します。
以上から、事前の十分な評価は必要ですが、現状のパラレルクエリの実装でO LAP 用途での使用は可能である、という結果となりました。
ただ、バグと見られる挙動も見られることから、より不安なくパラレルクエリを使用するためにも、常に最新バージョンでの使用を推奨するとともに、パラレルクエリ関連のさらなる進化と、これを司るプランナ・エグゼキュータのさらなる深化を働きかけていきます。

7.8. Appendix 2016年度検証モデルでの結果
検証A で述べたとおり、2016 年度のパラレルクエリ検証 で使用した検証用クエリを使用しての検証も行いました。

Page 62 of 67

PostgreSQL Enterprise Consortium

2016 年度検証データモデルでは、以下に示す条件で検証を行った結果、バージョン9.6 以降では、全クエリでパラレルクエリが動作しました。 2016 年度の検証においては
パーティション構成ありとなしの両方で検証を行いましたが、本検証においてはパーティション構成を採用していません。
表 7.23 検証条件
スト レージ
外付けストレージ装置

SQL 文

保持データ 量384 万行(1 日分) [12] を集計するSQL

1 年分(384 万× 366)

[12] Star Sch ema B en ch mark におけるScale Facto r とデータサイズを一致させる目的で、1 日あたりの件数を 2016 年度のパラレルクエリ検証 での設定値の半分(384 万件)に設定しています。この設定により、データサイズは110G B 程度となります。
バージョン毎の処理時間のグラフと表を以下に示します。

図 7.11 バージョンと処理時間の比較

Page 63 of 67

PostgreSQL Enterprise Consortium
表 7.24 バージョンと処理時間

9.5 処理時間(秒 )9.6 処理時間(秒 )9.6 性能向上
比 (倍 )

10 処理時間(秒 )10 性能向上比 (倍 )

11 処理時間(秒 )11 性能向上比 ( 倍 )366_01_10rec_1

166.1090

66.6200

2.493458.5179

2.838658.40632.8440366_01_10rec_2

154.2194

63.78482.417858.71232.626758.09522.6546366_02_1day_1

165.4775

67.7755

2.441659.2671

2.792159.19162.7956366_02_1day_2

154.8390

63.54172.436858.1420

2.663157.72052.6826366_03_15day_1

192.0502

73.41202.616164.3524

2.984463.93173.0040366_03_15day_2

159.1187

65.96432.412259.33592.681759.4298

2.6774366_04_10rec_jo in _1

165.4620

67.53072.450258.1532

2.845359.03452.8028366_04_10rec_jo in _1_h ash 163.4051

67.49192.421158.07032.813958.88822.7748366_04_10rec_jo in _1_n l

162.3903

67.3878

2.409858.5880

2.771758.3832

2.7815366_04_10rec_jo in _2

153.5317

63.68362.410958.64022.618258.02412.6460366_04_10rec_jo in _2_h ash 151.2344

63.3228

2.388358.9818

2.564158.18672.5991

366_04_10rec_jo in _2_n l63.8352

2.405059.2450

2.591357.93612.6499ク エリ

153.5228

検証の結果、クエリの処理時間について、バージョン9.5 との比較で、バージョン9.6 で2.38 倍(366_04_10rec_jo in _2_h ash )～2.61 倍(366_03_15day_1)、バージョン10で2.56 倍(366_04_10rec_jo in _2_h ash )～2.98 倍(366_03_15day_1)、バージョン11 で2.64 倍(366_04_10rec_jo in _2)～3.00 倍(366_03_15day_1)の高速化が認められました。 こちらの結果が示すとおり、バージョン10 とバージョン11 の間の差はわずかであり、この2 バージョンのパラレルクエリの基本性能は互角と言って差し支えないと考えます。

Page 64 of 67

PostgreSQL Enterprise Consortium

8. おわりに
今年度(2018 年度)は、Po stgreSQL エンタープライズ・コンソーシアム(PG ECo n s)の発足から数えて 7 年目となり、わたくしども技術部会ワーキンググループ 1(以下、本W G )も、今回で 7 期目となりました。本 W G では 2016 年度に PG ECo n s のワーキンググループの位置づけを見直してから、性能に加えて新技術の検証も行う「新技術検証ワーキンググループ」として活動しました。本報告書では、以下の 4 つのテーマの検証結果を報告しました。

1. Po stgreSQL 11 および前バージョン10 と比較したスケール性の検証
2. W in do w s 版Po stgreSQL とLin u x 版Po stgreSQL の性能比較検証
3. Po stgreSQL 11 で強化されたパラレルクエリ検証
4. Po stgreSQL 11 で実装された JITコンパイル機能の検証
以下では、今年度の検証活動を振り返って、具体的な進め方をご紹介することで、報告書のあとがきとしたいと思います。
まず、テーマの選定にあたっては、参加メンバからテーマを募るとともに、PG ECo n s の成果報告会や、オープンソースカンファレンスなどに参加されたお客様に記入いただくア
ンケートを参考に進めました。
例年通りの定点観測を行うことはもちろんのことながら、昨年度から引き続き、定点観測と同様の検証モデルを用いて W in do w s 版Po stgreSQL の性能検証を行っています。 また、検証テーマを考慮する上でPo stgreSQL 最新バージョンの新機能は外せません。バージョンが11 となった今回は強化されたパラレルクエリの他に、JITコンパイルが検証対象に選定されました。
各テーマごとの検証活動は担当する企業が主体となって進めます。各担当企業が作成した検証計画は、定例の会合で議論しました。提出された検証計画に対して「どのような観点で・何を計測することで、検証の目的が満たされるのか」検討します。その中で不足している観点や冗長な測定パターンが明らかになることもあります。こうして検証計画が固まると、約2 週間から 1 ヶ月程度、実機上で測定作業をします。得られたデータは整理されて会合に提出されます。「検証の目的に適ったデータが得られているか」確認し、「そのデータの意味するところは何か」考察して、少しでも質の高い結果が得られるように議論を重ねます。
こうした作業を積み重ねることで、単にベンチマークプログラムの測定値に留まらない、有用な結果が得られます。これらは、日常の業務で Po stgreSQL に深く係わり、その挙動やソースコードを熟知したメンバが集まって初めて達成できた成果です。PG ECo n s の会合は、異なる企業に属するメンバが集まって、専門的な意見を交わす貴重な場となっており、メンバの技術力の向上にも寄与しているものと思います。さらに 2017 年度から議論のためにチャットツールを導入したところ、以前よりも圧倒的に意見のやりとりの回数が増えました。これはメンバー間の連帯感向上、ひいては各検証における考察の質向上に寄与しました。
今回の報告書が皆様の Po stgreSQL の活用のご参考になれば幸いです。報告書へのご意見がございましたら、PG ECo n s までお寄せください。また、PG ECo n s の活動にご関心をお持ちの方は、是非、参加をご検討ください( ご連絡にはこちらのW eb サイト をご利用ください)。

(終わり)

Page 65 of 67

PostgreSQL Enterprise Consortium

9. 著者（企業・団体名順）
版
第1.0 版(2018 年度W G 1)

所属企業・ 団体名

部署名

氏名

NEC ソリューションイノベータ株式会社

サポートサービス事業部

近藤 太樹

NEC ソリューションイノベータ株式会社

サポートサービス事業部

小澤 怜

SRA O SS, In c. 日本支社

O SS 事業本部

近藤 雄太

NTTテクノクロス株式会社

Io Tイノベーション事業部

原田 登志

NTTテクノクロス株式会社

Io Tイノベーション事業部

勝俣 智成

NTTテクノクロス株式会社

Io Tイノベーション事業部

山本 育

日本電信電話株式会社

オープンソースソフトウェアセンタ

坂田 哲夫

富士通株式会社

ミドルウェア事業本部
データマネジメント・ミドルウェア事業部
グローバル技術部

並木 達郎

Page 66 of 67

PostgreSQL Enterprise Consortium

10. Appendix 検証環境
提供：日本ヒューレット・パッカード株式会社
定点観測（スケールアップ)/W in do w s 検証/パラレルクエリ検証での使用機器/設備

提供：富士通株式会社
JITコンパイル検証での使用機器/設備
項目

仕様

機種

PRIMERG Y RX2540M4

CPU

In tel(R) Xeo n G o ld
6140
(18 コア 36 スレッド) × 2

メモリ

256G B

内蔵ストレージ

SSD 700G B

Page 67 of 67