[pgsql-jp: 37456] Re: SQLの実行速度について

[Yoshio Kano]

加納です。
和山様、お返事ありがとうございます。

> 実際に120万件のテストデータを入れて試してみました。
> この場合、商品マスタテーブルが存在していると思われます。
> その商品マスタテーブルをshouhinとした場合、
> 以下のSQLで高速化できないでしょうか。
> 
> select *
> from shouhin a,history b
> WHERE a.id=b.id AND b.no = (select max(c.no) from history c
>  where c.id=a.id);
> 
> 8.736 ms

確かに、マスタテーブルは存在します。
ただ、マスタテーブルのレコードID=履歴テーブルの在庫商品ID
としていますので
「a.id=b.id」→「a.no=b.id」
「c.id=a.id」→「c.id=a.no」
となります。
※no=レコードID(serial),id=商品IDとしています。
　分かりにくくて申し訳ありません。

これらを考慮した上で作成したSQL
---------
SELECT
  *
FROM
  hohin AS a, history AS b
WHERE
  a.no=b.id
  AND
  b.no=(SELECT max(c.no) FROM history AS c WHERE c.id=a.no) 
---------
を実行すると、残念ながら結果が返ってきませんでした。
なぜか、shohinのnoやhistoryのnoにはインデックスを貼って
いるのですが、explainを見るとインデックスを使ってくれて
いません・・・。
過去ログを読んでも、なぜかインデックスを使ってくれない場合が
あるように書かれております。
むう、やはり、何かがおかしいのか・・・。


QUERY PLAN
Nested Loop  (cost=0.00..427102102.67 rows=1 width=302)
  Join Filter: ("outer".no = "inner".id)
  ->  Seq Scan on shohin a  (cost=0.00..968.28 rows=20728 width=234)
  ->  Index Scan using history_pkey on history b
      (cost=0.00..10304.02 rows=1 width=68)
        Index Cond: (b.no = (subplan))
        SubPlan
          ->  Aggregate  (cost=10301.00..10301.00 rows=1 width=4)
                ->  Seq Scan on history c
                    (cost=0.00..10301.00 rows=1 width=4)
                      Filter: (no = $0)
          ->  Aggregate  (cost=10301.00..10301.00 rows=1 width=4)
                ->  Seq Scan on history c
                    (cost=0.00..10301.00 rows=1 width=4)
                      Filter: (no = $0)