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