|
||||||||||||||||||
| 1 2 次のページ | ||||||||||||||||||
| GROUP BYによるチューニング | ||||||||||||||||||
|
前回から引き続き、オプティマイザに関する注意点を解説します。ここではDISTINCTをGROUP BYに置き換えることによって処理を効率化できる例を紹介しましょう。 |
||||||||||||||||||
| SELECT DISTINCTをSELECT…GROUP BYに置き換える | ||||||||||||||||||
|
DISTINCTは一般にソートが発生する負荷の高い処理です。しかも、重複が多ければ多いほどPostgreSQLでは極端に効率が落ちてしまいます。 図17を見てください。bid列に対してインデックスを作成すればソートが発生しないので高速化できるはずですが、この例のように極端に重複が多いケースではあまり効果がありません。 |
||||||||||||||||||
test=# EXPLAIN ANALYZE SELECT DISTINCT ON (bid) bid, aid FROM accounts;
|
||||||||||||||||||
|
図17:SELECT DISTINCTを使った場合 |
||||||||||||||||||
|
PostgreSQLは非常に効率の良いGROUP BYの処理ルーチンを備えているので、DISTINCTをGROUP BYで書き換えればかなり速度が向上します。 この例では、図18のように2倍以上高速になりました。しかもインデックスは不要です。 |
||||||||||||||||||
test=# EXPLAIN ANALYZE SELECT bid, min(aid) FROM accounts GROUP BY bid;
|
||||||||||||||||||
|
図18:SELECT… GROUP BYを使った場合 |
||||||||||||||||||
|
図18に登場するHashAggregateはGROUP BYの高速処理ルーチンです。ただし、HashAggregateは比較的多くのメモリを必要とします。もし問い合わせプランがHashAggregateではなくてSortになってしまう場合は、postgresql.confのsort_memを増やしてください |
||||||||||||||||||
|
1 2 次のページ |
||||||||||||||||||
|
書籍紹介 まるごと PostgreSQL! Vol.1
日本での市場シェアNo.1(オープンソースRDBMS部門)データベースソフトPostgreSQLの最新情報を、開発メンバーを含む豪華執筆陣が多面的かつ詳細に解説します。PostgreSQL用クラスタリング/レプリケーションソフト、PostgreSQL⇔Oracle移行、PostgreSQLによる大規模サイト構築法、新バージョンPostgreSQL 8.0先行レビュー、PostgreSQL用.NETデータプロバイダ等々、他では読めない貴重な記事が満載です。発売日:2004/12/08発売 定価:\1,890(本体 \1,800+税) |
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||


