[pgsql-jp: 37310] Re: PostgreSQL 7.2 におけるカラム削除について

CyCom 熊事 1G :鈴野幹典 mikinori.suzuno @ cy-com.co.jp
2006年 6月 29日 (木) 01:01:40 JST


鈴野です。

guinness0814 @ yahoo.co.jp wrote:
> 当初のDB設計が甘かったために今回のような現象が
> 発生していることが皆様のご指摘で分かりました。

遅くなる原因は単純に設計によるものではなく、
問い合わせの方法や表の定義も要因として考える必要があります。

無駄な全表走査や適切なINDEXが張られていないなど。

> カラム数が増え、冗長化が進行している今回の
> テーブル構成の場合、検索用テーブルを作成し、
> 外部keyにて元のテーブルから必要項目を参照すると
> いった構成に変更したいと思います。

新たに表を作るよりも上述の問い合わせの方法や別の方法を
再考してみては如何でしょうか?
問い合わせSQLが変更出来ないようなアプリケーションなのでしょうか?

> 一方で、午前4時にVACCUM(vacuumdb -a -z -e)を
> 行なっているのですが、その直後、同時アクセスが
> ない状態でテーブルに対して検索、更新をかけると
> 重たくなる現象を確認しました。
> しかしながら、日中は同時アクセスがあった場合でも、
> 問題なく処理される現象を確認しています。
>
> このような現象を経験された方はいらっしゃいます
> でしょうか。考えられる原因、及び解決策について、
> 皆様のお知恵をお聞かせください。

これは単純に
http://www.postgresql.jp/document/pg721doc/reference/sql-vacuum.html
にある通り、

以下、転載
-----
VACUUM FULL は、ディスクブロック数を最小にするためのブロックを跨るタプルの移
動など、
テーブルを縮小させるためにもっと高度な処理を行ないます。
この場合、かなり低速になり、また、処理中のテーブルに対する排他的ロックが必要
になります。
-----
って事ではないでしょうか?
古いバージョン(バージョン失念。7.3以前??)のPostgreSQLはVACUUM中には排他ロッ
クがかかるので、
言ってしまえばそれは仕様通りだと思います。

その話で言うとバージョンアップをしてみるという選択肢はありませんか?
8系ではWHERE句などの意味解釈が劇的に早くなっています。
8.1からはAUTO VACUUMもありますし。

テスト機でお試しになってみては如何でしょうか?
8系からネイティブなWindows版もありますしね。

では。

<?php --------------------------------------------
サイバーコム株式会社  熊本事業所  第1技術グループ
                      鈴野 幹典 (Mikinori Suzuno)

 〒860-0826 熊本市平田2-20-36 エレンスウエストビル
              E-mail: mikinori.suzuno @ cy-com.co.jp
               TEL: 096-324-7511 FAX: 096-324-7502
----------------------------------------------- ?>




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