今回は、Goldの「性能監視 - クエリ実行計画」からの出題です。
EXPLAIN ANALYZE SELECT * FROM pgbench_accounts a
JOIN pgbench_branches b ON (a.bid = b.bid) WHERE a.aid = 10000;
上記問い合わせの実行計画(EXPLAIN ANALYZE)を確認したところ、下記の出力であった。
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.00..2891.02 rows=1 width=461) (actual time=4.589..64.393 rows=1 loops=1)
Join Filter: (a.bid = b.bid)
-> Seq Scan on pgbench_accounts a (cost=0.00..2890.00 rows=1 width=97) (actual time=4.555..64.356 rows=1 loops=1)
Filter: (aid = 10000)
Rows Removed by Filter: 99999
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=364) (actual time=0.007..0.008 rows=1 loops=1)
Total runtime: 64.557 ms
(7 rows)
上記問い合わせをより高速にするために行うこととして最も適切なものをひとつ選びなさい。 なお、各テーブルの構成は下記のようになっている。
----------------------------------------------------
Table "public.pgbench_accounts"
Column | Type | Modifiers
---------- + --------------- + -----------
aid | integer | not null
bid | integer |
abalance | integer |
filler | character(84) |
----------------------------------------------------
----------------------------------------------------
Table "public.pgbench_branches"
Column | Type | Modifiers
---------- + --------------- + -----------
bid | integer | not null
bbalance | integer |
filler | character(88) |
Indexes:
"pgbench_branches_pkey" PRIMARY KEY, btree (bid)
----------------------------------------------------
pgbench_accountsを対象にANALYZEを実行する
※この例題は実際のOSS-DB技術者認定試験とは異なります。
【Aについて】
問合せにabalance列は利用していないため、pgbench_accountsのabalance列にインデックスを作成しても問い合わせの高速化は見込めません。
【Bについて】
pgbench_branchesのbidは主キーとして定義しているため、pgbench_branches_pkeyというインデックスが自動で作成されています。
pgbench_branchesのbidにインデックスを作成しても、この主キーのインデックスと重複しているため、問い合わせの高速化は見込めません。
なお、問題文の実行計画で主キーのインデックスが利用されていないのは、pgbench_branchesテーブルには1件しかデータがなくテーブルをスキャンした方が効率的であると判断されたためです。
【Cについて】
pgbench_accountsのスキャン(Seq Scan on pgbench_accounts a)の見積もり行数、取得実績行数ともにrows=1で乖離はないため、pgbench_accountsの統計情報を収集(ANALYZEを実行)しても、実行計画の変化に伴う問い合わせの高速化は見込めません。
【Dについて】
Rows Removed by Filter: 99999とあることから、pgbench_accountsから1件を取得するために全件(100000件)から99999件を除去していることが分かります。
pgbench_accountsのaid列にインデックスを作成することで、Seq ScanからIndex Scanになり、問い合わせの高速化が見込めます。
【Eについて】
pgbench_branchesのスキャン(Seq Scan on pgbench_branches b)の見積もり行数、取得実績行数ともにrows=1で乖離はないため、pgbench_accountsの統計情報を収集(ANALYZEを実行)しても、実行計画の変化に伴う問い合わせの高速化は見込めません。
よって、適切なものはDです。
今回の解説について、理解できないポイントがあればどんどん質問をお寄せ下さい。
※試験問題に関わるお問い合わせにつきましては、LPI-Japan事務局ではお応えできませんのでご了解ください。
© EDUCO All Rights Reserved.