第7回:オプティマイザに関するチューニング (3/3)

まるごと PostgreSQL!
PostgreSQLチューニング実践テクニック

第7回:オプティマイザに関するチューニング

著者:石井達夫(ISHII, Tatsuo)   2005/6/20
前のページ  1  2  3
関数を使うほうがよい場合もある

   作成したビューを使って同様の検索を行います(図15)。ご覧のように、100倍以上遅い結果になってしまいました。
test=# EXPLAIN ANALYZE SELECT * FROM acview WHERE aid QUERY PLAN
-------------------------------------------------------------------------
Subquery Scan acview (cost=11786.60..12286.61 rows=1 width=8) (actual time=794.317..973.167 rows=1 loops=1)
Filter: (aid ->Unique (cost=11786.60..12286.60 rows=1 width=8) actual time=794.280..973.126 rows=1 loops=1)
->Sort (cost=11786.60..12036.60 rows=100000 width=8) (actual time=794.275..900.418 rows=100000 loops=1)
Sort Key: accounts.bid, accounts.aid
->Seq Scan on accounts (cost=0.00..2640.00 rows=100000 width=8) (actual time=0.011..189.162 rows=100000 loops=1)
Total runtime: 975.301 ms
(7 rows)

図15:ビューを使用した場合


    これはaccountsテーブルを順スキャンしているからです。さらに、このビューの結果は最初のビューを使わない問い合わせの結果と必ずしも一致しません。このような場合は、SQL関数を使う方が適切です。

   まず、検索結果に対応する型を定義します。

CREATE TYPE acftype AS (bid INTEGER, aid INTEGER);

   次に、関数を定義します。

CREATE FUNCTION acfunc(INTEGER) RETURNS SETOF acftype AS 'SELECT DISTINCT ON (bid) bid, aid FROM accounts WHERE aid

   この関数を使って検索する例を図16に示します。ご覧のように、ビューを使わない場合と同程度の速度が得られました。

test=# EXPLAIN ANALYZE SELECT * FROM acfunc(1000);
QUERY PLAN
-------------------------------------------------------------------------
Function Scan on acfunc (cost=0.00..12.50 rows=1000 width=8) (actualtime=4.263..4.264 rows=1 loops=1)
Total runtime: 4.294 ms
(2 rows)

図16:SQL関数を使った場合


前のページ  1  2  3


石井達夫
著者プロフィール
石井達夫(ISHII, Tatsuo)
PostgreSQLの開発者、エバンジェリスト。本業でもPostgreSQLによるビジネスに関わっている。著書に「PostgreSQL完全攻略ガイド」「PHPxPostgreSQLで作る最強Webシステム」(技術評論社)などがある。


INDEX
第7回:オプティマイザに関するチューニング
  オプティマイザに関する注意点
  SMALLINT、BIGINTにもご用心
関数を使うほうがよい場合もある
PostgreSQLチューニング実践テクニック
第1回 postgresql.confによるチューニング(1)
第2回 postgresql.confによるチューニング(2)
第3回 VACUUMの活用によるチューニング
第4回 インデックスの活用によるチューニング
第5回 高度なインデックスの活用
第6回 統計情報の最適化
第7回 オプティマイザに関するチューニング
第8回 GROUP BYを使用したチューニング

人気記事トップ10

人気記事ランキングをもっと見る