From 58e47c40a05a1401c58a67e31bd77845ddb10829 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 25 Aug 2002 12:58:44 +0000 Subject: [PATCH] Update Japanese FAQ, from Jun Kuwamura --- doc/FAQ_japanese | 164 ++++++++++++++++++++++------------ doc/src/FAQ/FAQ_japanese.html | 142 +++++++++++++++++------------ 2 files changed, 191 insertions(+), 115 deletions(-) diff --git a/doc/FAQ_japanese b/doc/FAQ_japanese index 0d989f2f49..a4e2a92f1c 100644 --- a/doc/FAQ_japanese +++ b/doc/FAQ_japanese @@ -1,6 +1,6 @@ PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ) -原文最終更新日: Fri Apr 26 23:03:46 EDT 2002 +原文最終更新日: Thu Aug 22 19:20:40 EDT 2002 現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us) Maintainer of Japanese Translation: Jun Kuwamura (juk@postgresql.jp) @@ -19,10 +19,13 @@ docs/faq.html 日本語版のこの文書は 本家 "User's Lounge" の "Collection of FAQs" の "Japanese" という見出しのところにあります。また、以下のサイトにも あります。 + http://www.postgresql.jp/subcommittee/jpugdoc/ http://www.rccm.co.jp/~juk/pgsql/ http://www.linux.or.jp/JF/ この和訳についてお気づきの点は(juk@postgresql.jp)までメールでお寄せ下さい。 + + 2002年08月25日 桑村 潤 ] @@ -69,6 +72,8 @@ docs/faq.html 3.8) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？ 3.9) 自分のデータベース・ディレクトリにある pg_sorttemp.XXX ファイルは何ですか ？ +3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしな +くてはならないのはなぜですか？ 操作上の質問 @@ -111,6 +116,8 @@ docs/faq.html 4.23) 外部結合(outer join)はどのように実現しますか? 4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか？ 4.25) 関数で複数のロウまたはカラムを返すにはどうしますか？ +4.26) なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することがで +きないのでしょうか？ PostgreSQLの拡張についての質問 @@ -344,7 +351,7 @@ commercial-support.html 1.7) 最新版はどれですか -PostgreSQL の最新版はバージョン 7.2.1 です。 +PostgreSQL の最新版はバージョン 7.2.2 です。 我々は、4カ月毎にメジャーリリースを行なうことを計画しています。 @@ -457,24 +464,15 @@ pgsql-patches 性能(Performance) - PostgreSQLは二つのモードで走ります。普通のfsyncモードは、OSがクラッシュした - り、数秒後に電源が落ちたりしたときのために、トランザクションが完了する毎に - ディスクに書き込み、すべてのデータをディスクに保存します。このモードでは、 - ほとんどの商用データベースよりも遅くなりますが、その部分的な理由として、商 - 用のデータベースの中にはこのように保守的なディスク書き込みをデフォルトとし - ているものが少ないということもあります。 no-fsyncモードで、普通、PostgreSQL - は商用データベースよりも速くなりますが、しかしながら、OSのクラッシュでデー - タが破壊されるかもしれません。我々は、その中間モードを開発中で、それがうま - くゆくと、完全fsync モードほど性能を犠牲にすることなく、OSがクラッシュする - 30秒前までのデータ整合性を保てるようになります。 - - MySQLなどの特化型データベース・システムにくらべて、PostgreSQLの挿入／更新が - 遅いのは、トランザクションによるオーバーヘッドがあるからです。もちろん、 - MySQLには上記のFeaturesの節に示すような機能はまったくありません。我々は、 - PostgreSQLに柔軟性と機能性を組み込みながらも、絶えず、プロファイラーに掛け - たりソースコードを解析したりして、性能の改善を続けています。PostgreSQL と - MySQL とを比較している面白い Web ページが http://openacs.org/ - why-not-mysql.html にあります。 + PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ち + ます。ある面ではより早かったり、ほかの面ではより遅かったりします。 MySQLな + どの特化型データベース・システムにくらべて、PostgreSQLの挿入／更新が遅いの + は、トランザクションによるオーバーヘッドがあるからです。もちろん、MySQLには + 上記のFeaturesの節に示すような機能はまったくありません。我々は、PostgreSQL + に柔軟性と機能性を組み込みながらも、絶えず、プロファイラーに掛けたりソース + コードを解析したりして、性能の改善を続けています。PostgreSQL と MySQL とを + 比較している面白い Web ページが http://openacs.org/why-not-mysql.html にあ + ります。 PostgreSQLは、Unixプロセスを起動することによりユーザー接続を操作します。複 数のバックエンド・プロセスが情報をロックしながらデータ・バッファーを共有し @@ -514,15 +512,15 @@ PostgreSQL もちろん、この基盤は安いものではありません。維持し続けるためには毎月あるいは一 時の経費がかかります。もし、あなたやあなたの会社に、こうした努力のための資金を -助けるために施すことができるようでしたら、http://www.pgsql.com/pg_goodies から -寄付をお願いします。 +助けるために施すことができるようでしたら、 https://store.pgsql.com/shopping/ +index.php?id=1 から寄付をお願いします。 また、Webページには PostgreSQL,Inc とありますが、そこの"義援 (contributions)"ア イテムは PostgreSQL プロジェクトをサポートするためだけのためで、決して特定の会 社のための資金のためではありません。もし、手形 (check)の方が都合がよければ連絡 先の住所へお送り下さい。 -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ユーザー・クライアントの質問 2.1) PostgreSQL のための ODBC ドライバーはありますか？ @@ -535,6 +533,8 @@ ftp://ftp.PostgreSQL.org/pub/odbc/ [訳注: PsqlODBC の 日本語パッチを片岡裕生さん(kataoka@interwiz.koganei.tokyo.jp)が作られました: ●http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/index.html + 現在、最新版は井上博司さんのサイトにあります。 + ●http://w2422.nsk.ne.jp/~inoue/indexj.html ] @@ -600,7 +600,7 @@ ecpg 以下のものがあります: - ・ C (libpq) + ・ C (libpq, libpgeasy) ・ C++ (libpq++) ・ 埋め込みC (ecpg) ・ Java (jdbc) @@ -611,6 +611,8 @@ ecpg ・ C Easy API (libpgeasy) ・ 埋め込みHTML (PHP from http://www.php.net) +その他の利用可能なインターフェースは http://www.postgresql.org/interfaces.html +にあります。 [訳注： rubyの作者であるまつもと ゆきひろ(matz@ZetaBITS.COM)さんと、まつもと えいじ(ematsu@pfu.co.jp)さんが ruby の PostgreSQL インターフェースを作りました。現在の維持管理は斉藤 登さんがしています。 @@ -620,6 +622,8 @@ ecpg Bashコマンドラインでpostgres に問い合わせできます。 Perl のモジュールは古くからある Pg と DBI ドライバの DBD::Pg とがあり、 いずれも Edmund Mergl 氏によるもので CPAN サイトにあります。 + 永安悟史さんは Palm 版の libpq を開発されました。 + http://www.snaga.org/libpq/ ] @@ -801,6 +805,20 @@ ORDER BY ] +3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしな +くてはならないのはなぜですか？ + +PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から +7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャ +ーリリースでは、システムテーブルやデータファイルの内部フォーマットの変更をしば +しば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのた +めの後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出 +力し、それを新しい内部フォーマットを使って読み込むことができます。 + +同一リリースではディスク上でのフォーマットに変更はないので、アップグレードには +ダンプ／リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノ +ートには、pg_upgrade が利用可能なリリースかどうか記されています。 + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 操作上の質問 @@ -844,8 +862,8 @@ ALTER TABLE DROP COLUMN 制限は以下のとおりです。 データベースの最大サイズ? 制限無し (500GB のデータベースも存在します) テーブルの最大サイズ? 16TB -ロウの最大サイズ? 7.1以降で制限無し -フィールドの最大サイズ? 7.1以降で1GB +ロウの最大サイズ? 1.6TB +フィールドの最大サイズ? 1GB テーブル内での最大ロウ数? 制限無し テーブル内での最大カラム数? カラムの型により250-1600 テーブル内での最大インデクス数? 制限無し @@ -892,6 +910,8 @@ ALTER TABLE DROP COLUMN インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされる データを含む以上、それなりに大きくなります。 +NULLはビットマップに保存されていて、それらがわずかにスペースを使います。 + 4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのように して見つけ出しますか？ @@ -910,7 +930,7 @@ psql が最小サイズより大きく、問い合わせでそのわずかなパーセンテージのロウを選択する 時だけ、インデックスは使われます。これはインデックススキャンにより起こされるラ ンダムなディスクアクセスは、テーブルをストレートに読む順次走査よりも遅くなるこ -とがときどきあるからです。 +とがあるからです。 インデックスを使うかを決定するために、PostgreSQL はテーブルについての統計情報を 持たなければなりません。この統計情報は、VACUUM ANALYZEまたは、単に ANALYZE を使 @@ -923,13 +943,28 @@ psql に続く明示的ソートは、巨大なテーブルのインデックススキャンよりも普通は高速です 。 しかし、ORDER BYと組み合わされたLIMIT は、テーブルの小さな部分を返すためにたび -たびインデックスを使うでしょう。 +たびインデックスを使うでしょう。実際、MAX() や MIN() がインデックスを使わないと +しても、このような値を ORDER BY と LIMIT を使ってインデックスを使って取り出すこ +とが可能です: + SELECT col + FROM tab + ORDER BY col [ DESC ] + LIMIT 1 -LIKE あるいは ~ のようなワイルドカード演算子を使うとき、検索の開始が文字列の始 -めの部分に固定されているときにのみ、インデックスが使われます。そういうわけで、 -インデックスを使うためには、 LIKE パターンは%で始めないようにして、また、 ~(正 -規表現)パターンは^ で始めなくてはなりません。 [訳注：強制的にインデックスを使う -には SET enable_seqscan = off を実行します ] +LIKE あるいは ~ のようなワイルドカード演算子は特別な環境でしか使えません： + + + ・ 検索文字列が文字列の最初にききます。たとえば： + + □ LIKE パターンが%.で始まらない + □ ~ (正規表現) パターンは^.で始まらなければならない + + ・ 検索文字列を文字クラスから始めることはできません。たとえば、[a-e]。 + ・ ILIKE や ~* のように大文字小文字を区別しない検索は使えません。そのかわり、 + このFAQで後述する関数のインデックスが使えます。 + ・ initdb においては、デフォルトでCロケールが使われなくてはなりません。 + +[訳注：強制的にインデックスを使うには SET enable_seqscan = off を実行します。 ] 4.9) 問い合わせオブティマイザがどのように問い合わせを評価するのかを見るにはどう しますか？ @@ -984,8 +1019,8 @@ GEQO いますか？ ~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない -(case-insensitive)正規表現照合を行います。 PostgreSQL 7.1 以降では、大文字と小 -文字を区別しない LIKE 演算子を ILIKE といいます。 +(case-insensitive)正規表現照合を行います。大文字と小文字を区別しない LIKE 演算 +子を ILIKE といいます。 大文字と小文字を区別しない等値比較次のように表現できる： SELECT * @@ -1009,8 +1044,8 @@ Type Internal Name Notes -------------------------------------------------- "char" char 1 character CHAR(#) bpchar 指定された固定長となるように空白が詰められる -VARCHAR(#) varchar 長さの上限の無いテキスト -TEXT text 長さの制限は最大ロウ長による +VARCHAR(#) varchar 最大長のサイズを指定する、詰め物無し +TEXT text 長さに上限の無いテキスト BYTEA bytea 可変長のバイト配列(null-byte safe) 内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを @@ -1137,10 +1172,9 @@ dbdesign.html 4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはな ぜですか？ -もし、7.1 よりも古いバージョンをお使いの場合は、アップデートによってこの問題を -解決できるでしょう。それと、システムの仮想メモリーを全て使い果たしてしまってい -る可能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能性があ -ります。 postmaster を始動する前にこれを試してみて下さい： +おそらく、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、 +カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。 postmaster +を始動する前にこれを試してみて下さい： ulimit -d 262144 limit datasize 256m @@ -1192,8 +1226,8 @@ CURRENT_TIMESTAMP 4.23) 外部結合(outer join)はどのように実現しますか? -PostgreSQL 7.1 以降ではSQL標準構文を使う外部結合(アウタージョイン)をサポートし -ます。ここに、例題が2つあります。 +PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポートします。こ +こに 2つの例題があります。 SELECT * FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col); あるいは @@ -1231,6 +1265,16 @@ PostgreSQL developer.postgresql.org/docs/postgres/plpgsql-cursors.html の 23.7.3.3 節をご 覧下さい。 +4.26)なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができ +ないのでしょうか？ + +PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数 +が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されます +が、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時 +テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一 +時テーブルアクセスのために使うことです。これで、毎回クエリーのパースし直しを起 +こすでしょう。 + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PostgreSQLの拡張についての質問 @@ -1263,34 +1307,36 @@ developer.postgresql.org/docs/postgres/plpgsql-cursors.html [訳注： 日本語版の製作については以下の通りです。 - 最終更新日: 2002年05月08日 + 最終更新日: 2002年08月25日 翻訳者: 桑村 潤 (Jun Kuwamura ) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): - 田仲 稔(Minoru Tanaka ) - 石井 達夫(Tatsuo Ishii ) - 齊藤 知人(Tomohito Saitoh ) - 馬場 肇(Hajime Baba ) - 岡本 一幸(Kazuyuki Okamoto ) - 小菅 昭一(Shoichi Kosuge ) - 山下 義之(Yoshiyuki Yamashita ) - 境 真太郎(Sintaro Sakai ) - 生越 昌己(Masami Ogoshi ) - 石川 俊行(Toshiyuki Ishikawa ) - 本田 茂広(Shigehiro Honda ) - せせ じゅん(Jun Sese ) - 神谷 英孝(Hidetaka Kamiya ) + 田仲 稔(Minoru TANAKA ) + 石井 達夫(Tatsuo ISHII ) + 齊藤 知人(Tomohito SAITOH ) + 馬場 肇(Hajime BABA ) + 岡本 一幸(Kazuyuki OKAMOTO ) + 小菅 昭一(Shoichi Kosuge ) + 山下 義之(Yoshiyuki YAMASHITA ) + 境 真太郎(Sintaro SAKAI ) + 生越 昌己(Masami OGOSHI ) + 石川 俊行(Toshiyuki ISHIKAWA ) + 本田 茂広(Shigehiro HONDA ) + せせ じゅん(Jun SESE ) + 神谷 英孝(Hidetaka KAMIYA ) + 菅原 敦( +Atsushi SUGAWARA ) をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、 和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、その他、 直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの 皆さんに感謝します。 - 日本語版のこの文書は、以下からもたどれます。 http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問) - http://www.linux.or.jp/JF/(PostgreSQL-FAQ.j) + http://www.postgresql.jp/subcommittee/jpugdoc/JPUG文書・書籍関連分科会 + http://www.linux.or.jp/JF/Linux JFプロジェクト http://www.sra.co.jp/people/t-ishii/PostgreSQL/doc-jp/ なお、この和訳に関するご意見は(juk@postgresql.jp)までお寄せ下さい。 diff --git a/doc/src/FAQ/FAQ_japanese.html b/doc/src/FAQ/FAQ_japanese.html index 644995069a..48494357b5 100644 --- a/doc/src/FAQ/FAQ_japanese.html +++ b/doc/src/FAQ/FAQ_japanese.html @@ -7,7 +7,7 @@

PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ)

-原文最終更新日: Fri Apr 26 23:03:46 EDT 2002 +原文最終更新日: Thu Aug 22 19:20:40 EDT 2002

現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -35,10 +35,13 @@ http://www.PostgreSQL.org/docs/faq-english.html 日本語版のこの文書は 本家 "User's Lounge" の "Collection of FAQs" の "Japanese" という見出しのところにあります。また、以下のサイトにも あります。 + http://www.postgresql.jp/subcommittee/jpugdoc/ http://www.rccm.co.jp/~juk/pgsql/ http://www.linux.or.jp/JF/ この和訳についてお気づきの点は(juk@postgresql.jp)までメールでお寄せ下さい。 + + 2002年08月25日 桑村 潤 ] @@ -88,6 +91,7 @@ http://www.PostgreSQL.org/docs/faq-english.html 3.7) どのようなデバグ機能が使えますか？
3.8) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？
3.9) 自分のデータベース・ディレクトリにある pg_sorttemp.XXX ファイルは何ですか？
+3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしなくてはならないのはなぜですか？
@@ -121,6 +125,7 @@ http://www.PostgreSQL.org/docs/faq-english.html 4.23) 外部結合(outer join)はどのように実現しますか?
4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか？
4.25) 関数で複数のロウまたはカラムを返すにはどうしますか？
+4.26) なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができないのでしょうか？

PostgreSQLの拡張についての質問

@@ -361,7 +366,7 @@ UNIX

1.7) 最新版はどれですか

-

PostgreSQL の最新版はバージョン 7.2.1 です。 +

PostgreSQL の最新版はバージョン 7.2.2 です。

我々は、4カ月毎にメジャーリリースを行なうことを計画しています。

@@ -523,22 +528,10 @@ DBMS

性能(Performance)
-PostgreSQLは二つのモードで走ります。普通のfsyncモードは、OSがク -ラッシュしたり、数秒後に電源が落ちたりしたときのために、トランザクショ -ンが完了する毎にディスクに書き込み、すべてのデータをディスクに保存しま -す。このモードでは、ほとんどの商用データベースよりも遅くなりますが、そ -の部分的な理由として、商用のデータベースの中にはこのように保守的なディ -スク書き込みをデフォルトとしているものが少ないということもあります。 -no-fsyncモードで、普通、PostgreSQLは商用データベースよりも速く -なりますが、しかしながら、OSのクラッシュでデータが破壊されるかもしれま -せん。我々は、その中間モードを開発中で、それがうまくゆくと、完全fsync -モードほど性能を犠牲にすることなく、OSがクラッシュする30秒前までのデー -タ整合性を保てるようになります。 -

- +PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ちます。ある面ではより早かったり、ほかの面ではより遅かったりします。 MySQLなどの特化型データベース・システムにくらべて、PostgreSQLの挿入／ -更新が遅いのは、トランザクションによるオーバーヘッドがあるからです。も -ちろん、MySQLには上記のFeaturesの節に示すような機能はまったくあ +更新が遅いのは、トランザクションによるオーバーヘッドがあるからです。 +もちろん、MySQLには上記のFeaturesの節に示すような機能はまったくあ りません。我々は、PostgreSQLに柔軟性と機能性を組み込みながらも、絶えず、 プロファイラーに掛けたりソースコードを解析したりして、性能の改善を続け ています。PostgreSQL と MySQL とを比較している面白い Web ページが @@ -599,8 +592,9 @@ PostgreSQL

もちろん、この基盤は安いものではありません。維持し続けるためには 毎月あるいは一時の経費がかかります。もし、あなたやあなたの会社に、こうし た努力のための資金を助けるために施すことができるようでしたら、http://www.pgsql.com/pg_goodies + href= + "https://store.pgsql.com/shopping/index.php?id=1"> + https://store.pgsql.com/shopping/index.php?id=1 から寄付をお願いします。

また、Webページには PostgreSQL,Inc とありますが、そこの"義援 @@ -608,9 +602,8 @@ href= のためで、決して特定の会社のための資金のためではありません。もし、手形 (check)の方が都合がよければ連絡先の住所へお送り下さい。

- +

-

ユーザー・クライアントの質問

@@ -627,6 +620,8 @@ href= [訳注: PsqlODBC の 日本語パッチを片岡裕生さん(kataoka@interwiz.koganei.tokyo.jp)が作られました: ●http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/index.html + 現在、最新版は井上博司さんのサイトにあります。 + ●http://w2422.nsk.ne.jp/~inoue/indexj.html ] @@ -699,7 +694,7 @@ Programmer's Guide

以下のものがあります:

    -
  • C (libpq) +
  • C (libpq, libpgeasy)
  • C++ (libpq++)
  • 埋め込みC (ecpg)
  • Java (jdbc) @@ -710,7 +705,11 @@ Programmer's Guide
  • C Easy API (libpgeasy)
  • 埋め込みHTML (PHP from http://www.php.net)
-

+

その他の利用可能なインターフェースは + http://www.postgresql.org/interfaces.html + にあります。 + 

     [訳注：
@@ -722,10 +721,11 @@ Programmer's Guide
 	Bashコマンドラインでpostgres に問い合わせできます。
 	Perl のモジュールは古くからある Pg と DBI ドライバの DBD::Pg とがあり、
 	いずれも Edmund Mergl 氏によるもので CPAN サイトにあります。
+	永安悟史さんは Palm 版の libpq を開発されました。
+		http://www.snaga.org/libpq/
     ]
-

管理上の質問

@@ -858,9 +858,13 @@ PostgreSQL pg_options は postgresql.conf になっています。) ] - -

+

3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしなくてはならないのはなぜですか？

+

+PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から 7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャーリリースでは、システムテーブルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出力し、それを新しい内部フォーマットを使って読み込むことができます。 +

+同一リリースではディスク上でのフォーマットに変更はないので、アップグレードにはダンプ／リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノートには、pg_upgrade が利用可能なリリースかどうか記されています。 +

操作上の質問

@@ -917,8 +921,8 @@ PostgreSQL 
 データベースの最大サイズ? 	制限無し (500GB のデータベースも存在します)
 テーブルの最大サイズ?           16TB
-ロウの最大サイズ?                 7.1以降で制限無し
-フィールドの最大サイズ?         7.1以降で1GB
+ロウの最大サイズ?               1.6TB
+フィールドの最大サイズ?         1GB
 テーブル内での最大ロウ数?       制限無し
 テーブル内での最大カラム数?     カラムの型により250-1600
 テーブル内での最大インデクス数? 制限無し
@@ -964,6 +968,8 @@ PostgreSQL
 
 

 インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。
+
NULLはビットマップに保存されていて、それらがわずかにスペースを使います。
+
 
 

 
4.7)	定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか？
@@ -980,7 +986,7 @@ PostgreSQL
 ブルが最小サイズより大きく、問い合わせでそのわずかなパーセンテージのロウを
 選択する時だけ、インデックスは使われます。これはインデックススキャンによ
 り起こされるランダムなディスクアクセスは、テーブルをストレートに読む順次
-走査よりも遅くなることがときどきあるからです。
+走査よりも遅くなることがあるからです。
 
     
インデックスを使うかを決定するために、PostgreSQL はテーブルについ
 ての統計情報を持たなければなりません。この統計情報は、VACUUM
@@ -995,15 +1001,32 @@ ANALYZE
 のインデックススキャンよりも普通は高速です。

     しかし、ORDER BYと組み合わされたLIMIT 
 は、テーブルの小さな部分を返すためにたびたびインデックスを使うでしょう。
+実際、MAX() や MIN() がインデックスを使わないとしても、このような値を
+ORDER BY と LIMIT を使ってインデックスを使って取り出すことが可能です:
+
+
+    SELECT col
+    FROM tab
+    ORDER BY col [ DESC ]
+    LIMIT 1
+

 
     
 LIKE あるいは ~ のようなワイルドカード演算
-子を使うとき、検索の開始が文字列の始めの部分に固定されているときにのみ、
-インデックスが使われます。そういうわけで、インデックスを使うためには、
-LIKE パターンは%で始めないようにして、また、
-~(正規表現)パターンは^ で始めなくてはなりません。
+子は特別な環境でしか使えません：
+    
    
+    
  • 検索文字列が文字列の最初にききます。たとえば：
    • 
+    
      
+    
    • LIKE パターンが%.で始まらない
      • 
+    
    • ~ (正規表現) パターンは^.で始まらなければならない
      • 
+    
    
+    
  • 検索文字列を文字クラスから始めることはできません。たとえば、[a-e]。
    • 
+    
  • ILIKE や ~* のように大文字小文字を区別しない検索は使えません。そのかわり、このFAQで後述する関数のインデックスが使えます。
    • 
+    
  • initdb においては、デフォルトでCロケールが使われなくてはなりません。
    • 
+    

+    

 
 [訳注：
-	強制的にインデックスを使うには SET enable_seqscan = off を実行します
+	強制的にインデックスを使うには SET enable_seqscan = off を実行します。
 ]
 
 
@@ -1059,7 +1082,7 @@ Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
 

 
 

-~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 PostgreSQL 7.1 以降では、大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。
+~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。
 
 
 
大文字と小文字を区別しない等値比較次のように表現できる：
@@ -1101,8 +1124,8 @@ Type            Internal Name   Notes
 --------------------------------------------------
 "char"          char            1 character
 CHAR(#)         bpchar          指定された固定長となるように空白が詰められる
-VARCHAR(#)      varchar         長さの上限の無いテキスト
-TEXT            text            長さの制限は最大ロウ長による
+VARCHAR(#)      varchar         最大長のサイズを指定する、詰め物無し
+TEXT            text            長さに上限の無いテキスト
 BYTEA           bytea           可変長のバイト配列(null-byte safe)
@@ -1241,8 +1264,7 @@ http://www.comptechnews.com/~reaster/dbdesign.html

4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか？

-もし、7.1 よりも古いバージョンをお使いの場合は、アップデートによってこの問題を -解決できるでしょう。それと、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。 +おそらく、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。 postmaster を始動する前にこれを試してみて下さい： 

@@ -1302,7 +1324,7 @@ http://www.comptechnews.com/~reaster/dbdesign.html
 
 
4.23) 外部結合(outer join)はどのように実現しますか?

 

-PostgreSQL 7.1 以降ではSQL標準構文を使う外部結合(アウタージョイン)をサポートします。ここに、例題が2つあります。
+PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポートします。ここに 2つの例題があります。
 
 
 SELECT *
@@ -1345,6 +1367,12 @@ http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html 
 23.7.3.3 節をご覧下さい。

 
 
+

+
4.26)なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができないのでしょうか？

+
+PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されますが、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一時テーブルアクセスのために使うことです。これで、毎回クエリーのパースし直しを起こすでしょう。
+
+
 

 

 
PostgreSQLの拡張についての質問

@@ -1380,34 +1408,36 @@ http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html 
 [訳注：
   日本語版の製作については以下の通りです。
 
-  最終更新日:	2002年05月08日
+  最終更新日:	2002年08月25日
   翻訳者:	桑村 潤 (Jun Kuwamura <juk@postgresql.jp>)
 
   このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):
 
-		田仲 稔(Minoru Tanaka <Tanaka.Minoru@keiken.co.jp>)
-		石井 達夫(Tatsuo Ishii <t-ishii@sra.co.jp>)
-		齊藤 知人(Tomohito Saitoh <tomos@elelab.nsc.co.jp>)
-		馬場  肇(Hajime Baba <baba@kusastro.kyoto-u.ac.jp>)
-		岡本 一幸(Kazuyuki Okamoto <kokamoto@itg.hitachi.co.jp>)
-		小菅 昭一(Shoichi Kosuge <s-kosuge@str.hitachi.co.jp>)
-		山下 義之(Yoshiyuki Yamashita <dica@eurus.dti.ne.jp>)
-		境 真太郎(Sintaro Sakai <s_sakai@mxn.mesh.ne.jp>)
-		生越 昌己(Masami Ogoshi <ogochan@zetabits.com>)
-		石川 俊行(Toshiyuki Ishikawa <tosiyuki@gol.com>)
-		本田 茂広(Shigehiro Honda <fwif0083@mb.infoweb.ne.jp>)
-		せせ じゅん(Jun Sese <sesejun@linet.gr.jp>)
-		神谷 英孝(Hidetaka Kamiya <hkamiya@catvmics.ne.jp>)
+		田仲 稔(Minoru TANAKA <Tanaka.Minoru at keiken.co.jp>)
+		石井 達夫(Tatsuo ISHII <t-ishii at sra.co.jp>)
+		齊藤 知人(Tomohito SAITOH <tomos at elelab.nsc.co.jp>)
+		馬場  肇(Hajime BABA <baba at kusastro.kyoto-u.ac.jp>)
+		岡本 一幸(Kazuyuki OKAMOTO <kokamoto at itg.hitachi.co.jp>)
+		小菅 昭一(Shoichi Kosuge <s-kosuge at str.hitachi.co.jp>)
+		山下 義之(Yoshiyuki YAMASHITA <dica at eurus.dti.ne.jp>)
+		境 真太郎(Sintaro SAKAI <s_sakai at mxn.mesh.ne.jp>)
+		生越 昌己(Masami OGOSHI <ogochan at zetabits.com>)
+		石川 俊行(Toshiyuki ISHIKAWA <tosiyuki at gol.com>)
+		本田 茂広(Shigehiro HONDA <fwif0083 at mb.infoweb.ne.jp>)
+		せせ じゅん(Jun SESE <sesejun at linet.gr.jp>)
+		神谷 英孝(Hidetaka KAMIYA <hkamiya at catvmics.ne.jp>)
+		菅原 敦(
+Atsushi SUGAWARA <asugawar at f3.dion.ne.jp>)
 
   をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、
   和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、その他、
   直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの
   皆さんに感謝します。
 
-
   日本語版のこの文書は、以下からもたどれます。
 	http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問)
-	http://www.linux.or.jp/JF/(PostgreSQL-FAQ.j)
+	http://www.postgresql.jp/subcommittee/jpugdoc/JPUG文書・書籍関連分科会
+	http://www.linux.or.jp/JF/Linux JFプロジェクト
 	http://www.sra.co.jp/people/t-ishii/PostgreSQL/doc-jp/
 
   なお、この和訳に関するご意見は(juk@postgresql.jp)までお寄せ下さい。