PostgreSQLチューニング実践テクニック第7回

関数を使うほうがよい場合もある

作成したビューを使って同様の検索を行います（図15）。ご覧のように、100倍以上遅い結果になってしまいました。

test=# EXPLAIN ANALYZE SELECT * FROM acview WHERE aid  1000;

	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  1000)

	->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  $1 ORDER BY bid, aid' LANGUAGE SQL;

この関数を使って検索する例を図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関数を使った場合