PostgreSQL v9.5の新機能～CustomScan/Join Interface

v9.5の新機能
Custom Scan/Join Interface
KaiGai Kohei <kaigai@kaigai.gr.jp>

PostgreSQL - The most advanced
Open Source Relational Database
v9.5 New Feature
PostgreSQL Unconference/Tokyo May-20152
Custom-Scan
Interface
Custom-Join
Interface

Custom Scan/Join Interfaceが実現する事
▌クエリ実行計画の一部を、拡張モジュール実装の “何か” で置き換える
▌何を置き換える事ができるのか？
 Scan ... set_rel_pathlist_hook で候補パス追加
 Join ... set_join_pathlist_hook で候補パス追加
 Others ... planner_hookを使ってインジェクションすれば何でもアリ。
 局所最適にならないよう、注意は必要だが…。
▌応用例
 GPUアクセラレーションによる全体的なRDBMS性能の底上げ。
 PG-Strom (オタワで発表するんでヨロ)
 特定のテーブル同士のJoinをMaterialized Viewスキャンに透過的に置換え。
 特定のテーブルのうち、参照頻度の高い列だけを列指向形式でキャッシュ
 Scan/Joinの中間結果から統計情報を採取。値によるヒストグラム作成。
 ......など

クエリ実行計画
postgres=# EXPLAIN SELECT cat, AVG(x)
FROM t0 NATURAL JOIN t1 RIGHT JOIN t2 ON t0.aid=t2.bid OR t0.bid=t2.bid
WHERE atext like '%abc%' GROUP BY cat;
QUERY PLAN
------------------------------------------------------------------------------
HashAggregate (cost=979149.25..979149.58 rows=26 width=12)
Group Key: t0.cat
-> Nested Loop (cost=834.05..979139.33 rows=1985 width=12)
Join Filter: ((t0.aid = t2.bid) OR (t0.bid = t2.bid))
-> Seq Scan on t2 (cost=0.00..734.00 rows=40000 width=4)
-> Materialize (cost=834.05..281207.82 rows=996 width=20)
-> Hash Join (cost=834.05..281202.84 rows=996 width=20)
Hash Cond: (t0.aid = t1.aid)
-> Hash (cost=834.00..834.00 rows=4 width=4)
Filter: (atext ~~ '%abc%'::text)
(12 rows)

PostgreSQL クエリ処理の流れ (1/2)
▌リレーションに対する候補パスを列挙
 Base Relation
 Join Relation
▌プラナーが最も実行コストの小さな
パスを選択。
全てのテーブルを単一のJoin-Treeに
収めるまで結合順を試行錯誤
▌実行パスを元に、実行計画を作成
SQL
クエリ・パーサ（構文解析）
クエリ・オプティマイザ（最適化）
クエリ・エグゼキュータ（実行）
結果セット

PostgreSQL クエリ処理の流れ (2/2)
▌ExecInitNode
 実行ノードの初期化
▌ExecProcNode
 一行を生成して TupleTableSlot を返す
▌ExecEndNode
 実行ノードの終了処理
▌その他
 ExecReScan
 ExecMarkPos (optional)
 ExecRestrPos (optional)
SQL
クエリ・パーサ（構文解析）
クエリ・オプティマイザ（最適化）
クエリ・エグゼキュータ（実行）
結果セット

Custom Scan/Joinを使うには (1/3)
▌候補パスを追加する
typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
RelOptInfo *rel,
Index rti,
RangeTblEntry *rte);
extern PGDLLIMPORT set_rel_pathlist_hook_type set_rel_pathlist_hook;
typedef void (*set_join_pathlist_hook_type) (PlannerInfo *root,
RelOptInfo *joinrel,
RelOptInfo *outerrel,
RelOptInfo *innerrel,
JoinType jointype,
JoinPathExtraData *extra);
extern PGDLLIMPORT set_join_pathlist_hook_type set_join_pathlist_hook;
▌CustomPath 構造体
typedef struct CustomPath
{
Path path; // Path 共通部分
uint32 flags; // CUSTOMPATH_* flags
List *custom_private; // プライベート領域
const CustomPathMethods *methods; // コールバック関数
} CustomPath;

▌CustomPath  CustomScan
 プラナーがCustomPathを選択
CustomScanノードを生成する
必要がある
▌どういう事か？
 CustomPathから生成されるのは、
CustomScanだけではない。(将来的に)
CustomSort、CustomAgg、...
 プラン木はcopyObject()可能である事
GpuScanの例
/* Path information of GpuScan */
typedef struct {
CustomPath cpath;
/* RestrictInfo run on host */
List *host_quals;
/* RestrictInfo run on devices */
List *dev_quals;
} GpuScanPath;
▌CustomScan  CustomScanState
 エグゼキュータの開始時に、
CustomScanノードの内容に基づいて
CustomScanStateを初期化。
GpuScanの例
typedef struct {
GpuTaskState gts;
BlockNumber curr_blknum;
BlockNumber last_blknum;
HeapTupleData scan_tuple;
List *dev_quals;
cl_uint num_rechecked;
} GpuScanState;
CustomScanStateを継承

▌Executorコールバックを各自実装する
typedef struct CustomExecMethods
{
const char *CustomName;
/* Executor methods: mark/restore are optional, the rest are required */
void (*BeginCustomScan) (struct CustomScanState *node,
EState *estate,
int eflags);
TupleTableSlot *(*ExecCustomScan) (struct CustomScanState *node);
void (*EndCustomScan) (struct CustomScanState *node);
void (*ReScanCustomScan) (struct CustomScanState *node);
void (*MarkPosCustomScan) (struct CustomScanState *node);
void (*RestrPosCustomScan) (struct CustomScanState *node);
/* Optional: print additional information in EXPLAIN */
void (*ExplainCustomScan) (struct CustomScanState *node,
List *ancestors,
struct ExplainState *es);
} CustomExecMethods;

CustomJoinはどう見えるか？
Table.X Table.Y
Path ①
NestLoop
Path ②
HashJoin
Path ③
MergeJoin
Path ④
CustomScan
(GpuJoin)
Built-in
logics
clause
x.id = y.id
X Y X Y
NestLoop HashJoin
X Y
MergeJoin
X Y
GpuJoin Result set
of tables join
Join “後” の結果セットを
スキャンしているように見え
る。
▌CustomScanによる Join の置換え

結果セットのレコード型
table
(t0)
table
(t1)
table
(t2)
単純なスキャン複数のテーブルから成るジョイン
t0.a t0.b t0.c t0.d
結果セットのレコード型は、
常にテーブル定義と一致
t1.x t2.i t1.y t1.z t2.j t2.k
結果セットのレコード型は、
時と場合によって異なる

scanrelid == 0 と custom_scan_tlist
▌scanrelid == 0
 CustomScanが特定の実テーブルスキャンでない事を示す Magic Number
 custom_scan_tlist で指定されたレコード型をスキャンすると見なす。
 EXPLAINで、元々の列名を
表示する際の名前解決にも
使用される。
table
(t1)
table
(t2)
t1.x t2.i t1.y t1.z t2.j t2.k
CustomScan
scanrelid == 0
custom_scan_tlist

CustomScanを含むクエリ実行計画
postgres=# EXPLAIN SELECT cat, AVG(x)
FROM t0 NATURAL JOIN t1 RIGHT JOIN t2 ON t0.aid=t2.bid OR t0.bid=t2.bid
WHERE atext like '%abc%' GROUP BY cat;
QUERY PLAN
---------------------------------------------------------------------------
HashAggregate (cost=348362.37..348362.70 rows=26 width=12)
Group Key: t0.cat
-> Custom Scan (GpuPreAgg) (cost=2134.00..348362.24 rows=26 width=52)
Bulkload: On
Reduction: Local + Global
-> Custom Scan (GpuJoin) (cost=1134.00..347362.19 rows=1985 width=12)
Bulkload: On
Depth 1: Logic: GpuHashJoin, HashKeys: (aid), JoinQual: (aid = aid)
Depth 2: Logic: GpuNestLoop, JoinQual: ((aid = bid) OR (bid = bid))
-> Custom Scan (GpuScan) on t0 (cost=1000.00..143858.00 rows=10000060 ...
-> Custom Scan (MultiRels) (cost=834.05..343937.39 rows=4 width=4)
Hash keys: aid
nBatches: 1, Buckets: 1024, Buffer Usage: 2.33%
Filter: (atext ~~ '%abc%'::text)
-> Custom Scan (MultiRels) (cost=1134.00..347362.19 rows=40000 width=4)
nBatches: 1, Buffer Usage: 97.64%

CustomにJoinを実装してみた結果
▌SELECT cat, AVG(x) FROM t0 NATURAL JOIN t1 [, ...] GROUP BY cat; を
テーブル数を変えながら実行してクエリ応答時間を測定。
▌t0:1億行、t1~t10:それぞれ10万行を含む。全データはバッファにロード済み。
▌PostgreSQL v9.5devel + PG-Strom 5/26開発版、on CUDA7 (x86_64)
▌CPU: Xeon E5-2640, RAM: 256GB, GPU: NVIDIA GTX980, OS: RedHat EL7
81.71
122.96
165.05
214.64
261.51
307.18
356.20
406.59
468.59
520.45
8.38 9.02 8.84 10.33 11.47 13.21
14.48 17.15 19.37 21.72
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10
QueryExecutionTime[sec]
number of tables joined
PostgreSQL PG-Strom

v9.5に向けての Open Issue
拡張モジュールが
Child-Pathをプラン木に
変換できなくなってしまった!?

もふっ、もふもふ。
16

PostgreSQL v9.5の新機能～CustomScan/Join Interface

More Related Content

What's hot (20)

Similar to PostgreSQL v9.5の新機能～CustomScan/Join Interface (20)

More from Kohei KaiGai (20)

Recently uploaded (10)

PostgreSQL v9.5の新機能～CustomScan/Join Interface