[pgsql-jp: 28136] Re: PostgreSQL7.3について疑問
Tatsuo Ishii
t-ishii @ sra.co.jp
2002年 11月 30日 (土) 23:05:20 JST
石井です.
> PostgreSQL7.3について
>
> 1. エンコーディング変換関数の非常駐化によりロード
> モジュールのサイズが3M→2Mになったとのことですが、
> 日本語を使用するケースでもUNICODEを使用しなければ
> このメリットは享受できると思ってよいでしょうか。
はい.
> 2. 新しく実装されたスキーマについてpg_dumpでスキーマを
> 指定してダンプを取るようなことは可能になるでしょうか。
これは別のところで議論があったのでパス.
>
> 3. 新機能の行を返す関数についてレジュメのサンプルでは
> Language SQLとデモでC言語ということでしたが、plpgsqlは
> 使用可能でしょうか。
同様.
> 4. インデックスの性能劣化の改善について、SQLのオプティ
> マイズをした状態であのグラフになるとのことでしたが、
> どのようなオプティマイズ?が必要なのかわかるURLなど
> あれば教えてください。
> (現在運用しているシステムでは全てのテーブルを毎晩
> cronからReindexかけているのですが、その作業が不要に
> なることを期待しています)
URLは特にないと思います.強いて言えば,本家のpgsql-hackers MLのアーカ
イブ.
あの例はpgbenchを使ったものですが,pgbenchでは,非常に行数の少ない特定
のテーブルがあり,行数が少ないもので,必然的にオプティマイザは順スキャ
ンを選択します.これはテーブルにゴミが少ないときは妥当な選択ですが,ゴ
ミが増えるとインデックスを使った方が結果的に速くなります.ですから,手
動で
set enable_seqscan = false
として強制的にインデックスを使わせるようにしたのがお見せした結果です.
ただ,この設定はテーブル単位では設定できないので,インデックスを使って
欲しくないところまでインデックスを使うようになってしまう可能性がありま
す.ですから,いつもこの手が使えるわけではなく,実際にお使いのテーブル
とデータがどうなっているかに依存します.
> 5. デモのexttable関数(タブ区切りテキストファイルをSQLで
> 検索する関数)のソースを、是非、公開してください。
> # これだけは実際にお願いできました:-)
はい,そのうち.
> 6. 7.2.xで稼動しているシステムをバージョンアップする際、
> 特に気をつけなければいけないことはありますか?
> (pg_dumpでオブジェクト依存関係の移行が不完全なことは、
> 他の方の質問で出たので理解しました)
セミナーで話したこと以外は特にないと思います.
強いて言えば,Perl関係とかC++関係とかが,メインのソースツリーからAPIか
ら追い出されてしまったので,その辺をお使いの方には影響が大きいかなと.
--
Tatsuo Ishii
pgsql-jp メーリングリストの案内