[pgsql-jp: 33013] 日経システム構築の記事

Tatsuo Ishii t-ishii @ sra.co.jp
2004年 5月 27日 (木) 18:47:55 JST


石井です.

日経システム構築2004/6に「PostgreSQL 7.4.1の処理性能」と題した記事があ
り,PostgreSQL 7.3.6と7.4.1の性能比較を行っており,なかなか興味深く読
みました.全般的に,特に同時接続ユーザ数が多いときに7.4の性能が出てい
るということでした.ただ,一部の問い合わせではむしろ7.4の方が遅いこと
がある,というので気になってちょっと調べてみました.

SELECT col,count(*) FROM tab GROUP BY col;

のようなパターンで,テーブルのレコード数が1万件の時に7.4は7.3よりも2倍
遅い,ということでした.記事中ではこの違いは「7.3ではAggregate+Sortで
処理しているのに対し,7.4ではGroupAggregate+Sortを使っており,
GroupAggregateが遅い」と結論づけています.

まったく同じデータを作ることはできないので,pgbenchで10万件のデータを
作り,似たようなことをやってみました.たしかに7.4では

test=# EXPLAIN SELECT aid%10000, count(*) from ACCOUNTS GROUP BY 1;
                                 QUERY PLAN                                 
----------------------------------------------------------------------------
 GroupAggregate  (cost=11918.82..13168.82 rows=100000 width=4)
   ->  Sort  (cost=11918.82..12168.82 rows=100000 width=4)
         Sort Key: (aid % 10000)
         ->  Seq Scan on accounts  (cost=0.00..2890.00 rows=100000 width=4)
(4 rows)

となります.しかし,7.4には更に高速なHashAggregateというアルゴリズムが
あります.これはソートを必要としないので,高速になるはずです.ただし,
HashAggregateが使えるためにはsort_memがある程度の大きさでないといけな
くて,この場合では18000(約18MB)位からHashAggregateが使われるようになり
ました.

test=# SET SORT_MEM TO 18000;
SET
test=# EXPLAIN SELECT aid%10000, count(*) FROM accounts GROUP BY 1;
                              QUERY PLAN                              
----------------------------------------------------------------------
 HashAggregate  (cost=3390.00..3890.00 rows=100000 width=4)
   ->  Seq Scan on accounts  (cost=0.00..2890.00 rows=100000 width=4)
(2 rows)

GroupAggregateとHashAggregateの速度を比較すると,

GroupAggregate:	1696.261 ms
HashAggregate:	753.145 ms

と,2倍以上HashAggregateの方が高速でした.

というわけで,記事の方は前提条件が「チューニングなし」ということなので
しょうがないのですが,7.4を使うなら7.3とはちょっと違うチューニングテク
ニックが必要,という気がしました.
--
Tatsuo Ishii



pgsql-jp メーリングリストの案内