Update Japanese FAQ.

Jun Kuwamura

1 files changed, 98 insertions, 81 deletions

diff --git a/doc/FAQ_japanese b/doc/FAQ_japanese
index 6b8e4ff89d5..a0e6ebfb474 100644
--- a/doc/FAQ_japanese
+++ b/doc/FAQ_japanese
@@ -1,6 +1,6 @@
 PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ)
 
-原文最終更新日: Tue Sep 9 18:42:51 EDT 2003
+原文最終更新日: Mon Mar 29 00:07:11 EST 2004
 
 現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
 Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
@@ -44,7 +44,7 @@ Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
 1.11) PostgreSQLは西暦2000年問題(Y2K)に対応していますか？
 1.12) 開発チームにはどのように参加しますか？
 1.13) バグレポートはどのように発信しますか？
-1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？
+1.14) 他のDBMSと比べてPostgreSQLはどうなのですか？
 1.15) PostgreSQLを資金面で援助するにはどうすればよいですか？
 
                          ユーザー・クライアントの質問                          
@@ -75,7 +75,7 @@ Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
                                  操作上の質問                                  
                                                                                
 4.1) バイナリ・カーソルと通常カーソルとの違いは何ですか？
-4.2) 最初の数ロウのみを select するにはどうしますか？ランダムな行？
+4.2) 最初の数ロウのみを select するにはどうしますか？ランダムなロウ？
 4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか？
 4.4) テーブルからカラムの削除、あるいは、データ型を変更するにはどうしますか？
 4.5) ロウ、テーブル、データベースの最大サイズは？
@@ -134,18 +134,22 @@ Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
                                                                                
 1.1) PostgreSQL とは何ですか？何と読みますか？
 
-Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。
+Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。この発音を聞きた
+い人のために、オーディオファイルを http://www.postgresql.org/postgresql.mp3 に
+用意してあります。
 
 PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理
-システムの改良版です。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデー
-タ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡
-張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利
-用できます。
+システムの改良版です（このため、今でもときどき "Postgres" と呼ばれることがあり
+ます）。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)
+を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL の
+サブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。
 
 PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加している開発者達のチ
 ームですべて行なわれています。現在の座長は Marc G. Fournier (
 scrappy@PostgreSQL.org )です。(下記の1.6節に参加の仕方があります。)現在、このチ
-ームが PostgreSQL 開発のすべての面倒をみています。
+ームが PostgreSQL 開発のすべての面倒をみています。このチームはコミュニティプロ
+ジェクトであり、いかなる企業によっても制御を受けません。参加したければ、http://
+www.PostgreSQL.org/docs/faqs/FAQ_DEV.html にある開発者向けのFAQを見てください。
 
 Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢
 の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。
@@ -167,7 +171,7 @@ PostgreSQL は下記の著作権に従います。
 
 PostgreSQL Data Base Management System
 
-Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group Portions
+Portions Copyright (c) 1996-2004, PostgreSQL Global Development Group Portions
 Copyright (c) 1994-6 Regents of the University of California
 
 Permission to use, copy, modify, and distribute this software and its
@@ -189,14 +193,14 @@ SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
 
         POSTGRESQL データベース管理システム
 
-        部分的著作権 (c) 1996-2002, PostgreSQL国際開発チーム
+        部分的著作権 (c) 1996-2004, PostgreSQL国際開発チーム
         部分的著作権 (c) 1994-6 カリフォルニア大学本校
 
 
           本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章
         およびこれに続く二つの段落が全ての複製に添付されている限りにおい
-        て、使用、複製、修正および配付の許可を、いかなる目的であっも、無
-        償でかつ同意書無しに行なえることをここに認めます。
+        て、使用、複製、修正および配付の許可を、いかなる目的であっても、
+        無償でかつ同意書無しに行なえることをここに認めます。
         
           カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を
         含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた
@@ -220,18 +224,18 @@ SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
 
 1.3) PostgreSQL の動作環境は？
 
-一般的に、最近のUnix互換プラットホームならばPostgreSQLをはしらせられるはずです
-。リリースの時点で実際にテストを行なったことの報告がなされたプラットホームにつ
-いてはインストール手引書に列挙してあります。
+一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働させられるはずで
+す。リリースの時点で実際にテストを行なったことの報告がなされたプラットホームに
+ついてはインストール手引書に列挙してあります。
 
 1.4) Unix以外の移植版で使えるものは？
 
 クライアント
 
-MS Windows プラットホーム上で走せるために、libpq C ライブラリ、psql、その他のイ
-ンターフェイス、および、クライアントアプリケーションをコンパイルすることは可能
-です。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポートさ
-れている Unix プラットホーム上で走るサーバと通信します。
+MS Windows プラットホーム上で走らせるために、libpq C ライブラリ、psql、その他の
+インターフェイス、および、クライアントアプリケーションをコンパイルすることは可
+能です。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポート
+されている Unix プラットホーム上で走るサーバと通信します。
 
 Win32 libpq ライブラリと psql を作るために、win32.mak が配布に含まれてます。
 PostgreSQLは ODBC クライアントとも通信できます。
@@ -306,8 +310,12 @@ pgsql-general-request@PostgreSQL.org へ送って下さい。
 ダイジェスト版は、メインリストで受信するメッセージが 30k 程度溜る毎にダイジェス
 ト版リストのメンバーに送付されます。
 
-バグレポート用のメーリングリストもあります。このリストへの参加は "本文"といっし
-ょに： bugs-request@PostgreSQL.org へ電子メールを送って下さい。
+バグレポート用のメーリングリストもあります。このリストへの参加は "本文" に：
+
+        subscribe
+        end
+
+と書いてbugs-request@PostgreSQL.org へ電子メールを送って下さい。
 
 開発者の議論のためのメーリングリストも利用できます。このリストへの参加は電子メ
 ールの本文に：
@@ -319,8 +327,9 @@ pgsql-general-request@PostgreSQL.org へ送って下さい。
 
 http://www.PostgreSQL.org
 
-EFNet と OpenProjects に #PostgreSQL という IRC チャンネルもあります。 UNIX コ
-マンドでirc -c '#PostgreSQL' "$USER" irc.phoenix.net を使っています。
+EFNetに #PostgreSQL という IRC チャンネルもあります。 UNIX コマンドで irc -c '#
+PostgreSQL' "$USER" irc.phoenix.net. あるいは、 irc -c '#PostgreSQL' "$USER"
+irc.freenode.net. を使って参加できます。
 
     [訳注:
           1999年7月23日、日本PostgreSQLユーザー会(にほん ぽすとぐれす ゆーざー かい)、略称JPUG
@@ -348,7 +357,7 @@ EFNet と OpenProjects に #PostgreSQL という IRC チャンネルもあります。 UNIX コ
 
 1.7) 最新版はどれですか
 
-PostgreSQL の最新版はバージョン 7.3.4 です。
+PostgreSQL の最新版はバージョン 7.4.2 です。
 
 我々は、6〜8カ月毎にメジャーリリースを行なうことを計画しています。
 
@@ -454,7 +463,7 @@ http://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (バグツール)のページ
 それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/で、もっと新しいバージョン
 の PostgreSQL あるいはパッチをさがしてみて下さい。
 
-1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？
+1.14) 他のDBMSと比べてPostgreSQLはどうなのですか？
 
 ソフトウェアを計る方法にはいくつかあります。機能と性能と信頼性とサポートと価格
 です。
@@ -468,13 +477,16 @@ http://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (バグツール)のページ
 性能(Performance)
     PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ち
     ます。ある面ではより早かったり、ほかの面ではより遅かったりします。MySQLなど
-    の特化型データベース・システムにくらべて、PostgreSQLの挿入／更新が遅いのは
-    、トランザクションによるオーバーヘッドがあるからです。もちろん、MySQLには上
-    記のFeaturesの節に示すような機能はまったくありません。我々は、PostgreSQLに
-    柔軟性と機能性を組み込みながらも、絶えず、プロファイラーに掛けたりソースコ
-    ードを解析したりして、性能の改善を続けています。PostgreSQL と MySQL とを比
-    較している面白い Web ページがhttp://openacs.org/philosophy/
-    why-not-mysql.htmlにあります。
+    の特化型データベース・システムにくらべて、PostgreSQL は複数ユーザや複雑な問
+    い合わせ、また、 read/write 問い合わせのロードがより高速です。MySQLは少ない
+    ユーザでの単純な SELECT 問い合わせでは高速です。もちろん、MySQLには上記の
+    Featuresの節に示すような機能はまったくありません。我々は、PostgreSQLに柔軟
+    性と機能性を組み込みながらも、絶えず、プロファイラーに掛けたりソースコード
+    を解析したりして、性能の改善を続けています。PostgreSQL と MySQL とを比較し
+    ている面白い Web ページがhttp://openacs.org/philosophy/why-not-mysql.htmlに
+    あります。また、MySQLは、製品をオープンソースを通じて配布して、クローズソー
+    スソフトウェアとしての商用ライセンスを要求する企業でもあり、PostgreSQLのよ
+    うなオープンソース開発コミュニティではありません。
     PostgreSQLは、Unixプロセスを起動することによりユーザー接続を操作します。複
     数のバックエンド・プロセスが情報をロックしながらデータ・バッファーを共有し
     ます。マルチCPUでは、簡単に複数のバックエンドをそれぞれのCPUで走らせること
@@ -491,9 +503,9 @@ http://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (バグツール)のページ
     てくれる、開発者やユーザの大きな集まりへの接点を提供しています。我々は問題
     の解決を保証することはできませんが、商用データベースであっても常に解決され
     るわけではありません。開発者や、ユーザ・コミュニティ、マニュアル類、それに
-    、ソースコードなどへ直接アクセスできることよって、PostgreSQLのサポートは、
-    他のDBMSサポートよりも優れたものとなっています。御要望に答えて、事柄毎の商
-    用サポートなどもあります（FAQ1.6節をご覧下さい）。
+    、ソースコードなどへ直接アクセスできることによって、PostgreSQLのサポートは
+    、他のDBMSサポートよりも優れたものとなっています。御要望に答えて、事柄毎の
+    商用サポートなどもあります（FAQ1.6節をご覧下さい）。
 価格(Price)
     PostgreSQLの利用は、商用でも非商用でも、すべて無料です。上記に示してあるBSD
     スタイルの使用許諾に外れない限り、PostgreSQLのコードを制限無しで商品に組み
@@ -579,11 +591,11 @@ www.php.net/にあります。
 2.3) PostgreSQL にグラフィカル・ユーザインターフェイスはありますか？
 
 もちろん、PostgreSQL へのグラフィカルインターフェイスがいくつかあります。その中
-にPgAccess http://www.pgaccess.com も含まれます。 PgAdmin II (http://
-www.pgadmin.org Win32-only)もあります。 RHDB Admin (http://sources.redhat.com/
-rhdb/ )と Rekall ( http://www.thekompany.com/products/rekall/, proprietary)もあ
-ります。 PHPPgAdmin ( http://phppgadmin.sourceforge.net/ ) はPostgreSQLへのWeb
-ベースのインターフェイスを提供します。
+にPgAccess http://www.pgaccess.com も含まれます。 PgAdmin III (http://
+www.pgadmin.org)もあります。 RHDB Admin (http://sources.redhat.com/rhdb/ )と
+Rekall ( http://www.thekompany.com/products/rekall/, proprietary)もあります。
+PhpPgAdmin ( http://phppgadmin.sourceforge.net/ ) はPostgreSQLへのWebベースのイ
+ンターフェイスを提供します。
 
 PgAccess と呼ばれる素晴らしいグラフィカル・ユーザ・インターフェイスがあり、この
 配布と共に出荷されます。PgAccess にはレポート・ジェネレータもあります。Web ペー
@@ -660,9 +672,9 @@ Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあ
 3.5) 他のホストからの接続はどのように制御しますか？
 
 既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続し
-か許しません。postmaster 起動に -i フラッグを加え、$PGDATA/pg_hba.conf ファイル
-を適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できな
-いでしょう。これによりTCP/IPの接続が可能になります。
+か許しません。postgresql.conf の中の tcpip_sockets を有効にし、$PGDATA/
+pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマ
+シンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。
 
 操作不能なセマフォも過度のデータベースアクセス中にクラッシュを引き起こすことが
 あります。
@@ -670,9 +682,9 @@ Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあ
 3.6) より良い性能を得るためには、データベース・エンジンをどのように調整すれば良
 いですか？
 
-確かにインデックスは問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL が
-どのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのイン
-デックスが使われているかを見ることができます。
+確かにインデックスは問い合わせの速度を増します。EXPLAIN ANALYZEコマンドで
+PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そし
+て、どのインデックスが使われているかを見ることができます。
 
 もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを
 行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次
@@ -688,9 +700,9 @@ Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあ
 
 postmaster -B オプションを使ってバックエンド・プロセスにより使われる共有メモリ
 ー・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、
-カーネルの共有メモリー空間の制限値を越えてしまっうために postmaster が走らなく
-なるでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64
-です。
+カーネルの共有メモリー空間の制限値を越えてしまうために postmaster が走らなくな
+るでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64 で
+す。
 
 バックエンドを -S オプションを使って、それぞれのバックエンド・プロセスが一時的
 な並べ替えによって使うメモリーの最大サイズを増やすこともできます。その -S の値
@@ -722,13 +734,13 @@ Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オ
 プションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファ
 イルを生成することに注意しなくてはなりません。
 
-もし、postmasterが走っていなければ、postgresバックエンドをコマンド行から走らせ
-ることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的の
-ときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注
-意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使
-って何が起きているかを見ることができます。postmaster からバックエンドを開始した
-わけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話
-の問題が重複することはありません。
+もし、postmasterが走っていなければ、postgresバックエンドをコマンドラインから走
+らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目
+的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになること
+に注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガ
+を使って何が起きているかを見ることができます。postmaster からバックエンドを開始
+したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの
+対話の問題が重複することはありません。
 
 もし、postmasterが走っていれば、あるウィンドウで psqlを開始すると、psql で使わ
 れる postgres プロセスのPIDが見つかります。デバッガを使って postgresのPIDにアタ
@@ -755,7 +767,7 @@ postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があり
 
 既定の最大プロセスは32プロセスです。-Nに適切な値を引数にしてpostmasterを再起動
 するか、PostgreSQL.conf を修正することによって、その値を増やすことができます。
-。既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/
+既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/
 config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの
 --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。
 
@@ -813,7 +825,7 @@ PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から
 
 詳述は、オンラインマニュアルで DECLARE を見て下さい。
 
-4.2) 最初の数ロウのみを SELECTするにはどうしますか？ランダムな行？
+4.2) 最初の数ロウのみを SELECTするにはどうしますか？ランダムなロウ？
 
 オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使っ
 てみて下さい。
@@ -824,7 +836,7 @@ PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から
 ウだけで評価できるかもしれませんが、でなれば、PostgreSQL は意図したロウが生成さ
 れるまですべてのロウを評価しなければならないかもしれません。
 
-ランダムな行をSELECTするには、次の文を使います：
+ランダムなロウをSELECTするには、次の文を使います：
 
     SELECT col
     FROM tab
@@ -833,10 +845,14 @@ PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から
 
 4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか？
 
-psqlのソースコードとして書かれた pgsql/src/bin/psql/describe.c ファイルを読むこ
-とがその答えです。そこには、psqlのバックスラッシュコマンドによる出力のためのSQL
-コマンドが含まれています。 psql に -E オプションをつけて起動すれば、与えたコマ
-ンドを実行するための問い合わせが出力されます。
+psqlの中で、 \dt コマンドを使ってテーブルを見ます。psql の中のコマンドの完全な
+リストには \? を使えます。あるいは、psqlのソースコードのpgsql/src/bin/psql/
+describe.cファイルを見るることもできて、その中にはpsqlのバックスラッシュコマン
+ドの出力を生成するSQLコマンドが含まれています。また、psqlを -E オプションと一緒
+に開始すると、実行させたコマンドを実行するために使う問い合わせを出力するように
+なります。PostgreSQLはまた、SQLi対応の INFORMATION SCHEMA インターフェースを用
+意していて、データベースについての情報を得るために問い合わせを使うことができま
+す。
 
 4.4) テーブルからカラムの削除、あるいは、データ型を変更するにはどうしますか？
 
@@ -867,7 +883,7 @@ VACUUM FULL tabをしたほうが良いかもしれません。
 
 制限は以下のとおりです。
 
-データベースの最大サイズ?       制限無し (4 TB のデータベースも存在します)
+データベースの最大サイズ?       制限無し (32 TB のデータベースも存在します)
 テーブルの最大サイズ?           32TB
 ロウの最大サイズ?               1.6TB
 フィールドの最大サイズ?         1GB
@@ -918,7 +934,7 @@ VACUUM FULL tabをしたほうが良いかもしれません。
 インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされる
 データを含む以上、それなりに大きくなります。
 
-NULLはビットマップに保存されていて、それらがわずかにスペースを使います。
+NULLはビットマップとして保存されていて、それらがわずかにスペースを使います。
 
 4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのように
 して見つけ出しますか？
@@ -1031,7 +1047,7 @@ GEQO モジュールは、沢山のテーブルを結合するときに、遺伝的アルゴリズム(GA)で問合
 (case-insensitive)正規表現照合を行います。大文字と小文字を区別しない LIKE 演算
 子を ILIKE といいます。
 
-大文字と小文字を区別しない等値比較次のように表現できる：
+大文字と小文字を区別しない等値比較は次のように表現できる：
 
     SELECT *
     FROM tab
@@ -1074,12 +1090,12 @@ VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制
 トです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランク
 を詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL
 のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくら
-いの性能特性ををもちます。
+いの性能特性をもちます。
 
 4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？
 
-PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自
-動作成します。たとえば、
+PostgreSQL は SERIAL データ型をサポートします。カラム上にシーケンスを自動作成し
+ます。たとえば、
 
         CREATE TABLE person ( 
                 id   SERIAL, 
@@ -1093,7 +1109,6 @@ PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自
                 id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
                 name TEXT 
         );
-        CREATE UNIQUE INDEX person_id_key ON person ( id );
 
     [訳注：
         CREATE UNIQUE INDEX person_id_key ON person ( id );
@@ -1104,7 +1119,7 @@ PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自
 下さい。
 
 また、各ロウのOIDフィールドを一意値として使うこともできます。しかしながら、もし
-もデータベースをダンプしてりロードする必要がある場合は、OIDを温存するために
+もデータベースをダンプしてリロードする必要がある場合は、OIDを温存するために
 pg_dump で -oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があ
 ります。 Bruce Momjian の(http://www.PostgreSQL.org/docs/aw_pgsql_book)の
 Numbering Rowsの章にありあます。
@@ -1242,10 +1257,10 @@ CURRENT_TIMESTAMPを使います:
 
 4.22) なぜ、INを使う副問い合わせがとても遅いのですか？
 
-現在、外部問い合わせの各ロウについて副問い合わせの結果を順番にスキャンすること
-により、副問い合わせを外部問い合わせに結合しています。もし、副問い合わせが数行
-しか返さず、外部問い合わせが沢山の行を返すなら、当面はINをEXISTSで置き換えるこ
-とです：
+7.4 より前のバージョンでは、副問い合わせは、副問い合わせの結果を外部問い合わせ
+の各ロウについて順次走査することによって、外部の問い合わせに結合させられる。副
+問い合わせがわずかなロウしか返さず、外部問い合わせが沢山のロウを返す場合は、IN
+が最も早いです。他の問い合わせを高速化するには、INをEXISTSに置換します:
 
         SELECT *
         FROM tab
@@ -1257,8 +1272,10 @@ CURRENT_TIMESTAMPを使います:
         FROM tab
         WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col)
 
-とします。これが手っ取り早いですが、subcolは索引付きカラムであるべきです。ここ
-で示した問題は7.4で修正されます。
+とします。これが手っ取り早いですが、subcolは索引付きカラムであるべきです。
+
+バージョン7.4以降では、INは、通常の問い合わせと同様の洗練されたジョインの技術を
+実際に使い、EXISTSを使うことを好みます。
 
 4.23) 外部結合(outer join)はどのように実現しますか?
 
@@ -1312,8 +1329,8 @@ PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数
 が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されます
 が、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時
 テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一
-時テーブルアクセスのために使うことです。これで、毎回クエリーのパースし直しを起
-こすでしょう。
+時テーブルアクセスのために使うことです。これで、毎回問い合わせをパースし直すこ
+とになるでしょう。
 
 4.27) どのようなリプリケーションオプションを利用できますか?
 
@@ -1377,7 +1394,7 @@ http://www.csra.co.jp/~mitani/jpug/pgreplicate/ ]
 [訳注：
   日本語版の製作については以下の通りです。
 
-  最終更新日:   2003年09月20日
+  最終更新日:   2004年04月28日
   翻訳者:       桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>)
 
   このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):