SMALLINT、BIGINTにもご用心

同じような問題がSMALLINT、BIGINTでも起こります。たとえば、次のようにテーブルとインデックスを作成したとします。

CREATE TABLE t1(d BIGINT);
CREATE INDEX t1index ON t1(d);

このとき、次のような検索では作成したインデックスが使われません。

 SELECT * FROM t1 WHERE d > 100;

これは、100が自動的にINTEGER(INT4)に変換されるため、BIGINTと一致しなくなるからです。このような場合は次のようにキャストを利用すればインデックスが使われる可能性があります。

SELECT * FROM t1 WHERE d > 100::INT8;

ビューは万能ではない

ビューは複雑な問い合わせを単純にしてくれますが、性能上注意すべき問題もあります。次に、例を示します。まずデータを用意します。

 $ pgbench -i test

図14を下から順に見ていきます。まずaccounts_pkeyを使って「aid 1000」を満たす行を選びます。次にその結果をソートし、最後にDISTINCT ONの処理（Unique …）を行っています。

 test=# EXPLAIN ANALYZE SELECT DISTINCT ON (bid) bid, aid FROM accounts WHERE aid 1000 ORDER BY bid, aid;
QUERY PLAN
-------------------------------------------------------------------------
 Unique (cost=74.79..79.33 rows=1 width=8) (actual time=4.961..6.264 rows=1 loops=1)
->Sort (cost=74.79..77.06 rows=907 width=8) (actual time=4.959..5.530 rows=999 loops=1)
Sort Key: bid, aid
->Index Scan using accounts_pkey on accounts (cost=0.00..30.24rows=907 width=8) (actual time=0.119..2.860 rows=999 loops=1)
Index Cond: (aid 1000)
 Total runtime: 6.409 ms
(6 rows)

図14：インデックスを使った場合

これをビューにしてみましょう。「aid 1000」の部分は可変にしたいので、ビューには含めないことにします。

test=# CREATE VIEW acview AS SELECT DISTINCT ON (bid) bid, aid FROM accounts ORDER BY bid, aid;

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