From 58e47c40a05a1401c58a67e31bd77845ddb10829 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 25 Aug 2002 12:58:44 +0000 Subject: Update Japanese FAQ, from Jun Kuwamura --- doc/src/FAQ/FAQ_japanese.html | 142 +++++++++++++++++++++++++----------------- 1 file changed, 86 insertions(+), 56 deletions(-) (limited to 'doc/src') diff --git a/doc/src/FAQ/FAQ_japanese.html b/doc/src/FAQ/FAQ_japanese.html index 644995069ac..48494357b56 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

以下のものがあります:

-

+

その他の利用可能なインターフェースは + 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)までお寄せ下さい。
-- 
cgit v1.2.3