From 448ca1fe0b419dd789c055e0ea6b1993e80d9282 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 4 Jun 2002 05:12:21 +0000 Subject: Update Japanese FAQ, from Jun Kuwamura --- doc/src/FAQ/FAQ_japanese.html | 88 ++++++++++++++++++++++++------------------- 1 file changed, 50 insertions(+), 38 deletions(-) (limited to 'doc/src') diff --git a/doc/src/FAQ/FAQ_japanese.html b/doc/src/FAQ/FAQ_japanese.html index fb5a4ee3892..644995069ac 100644 --- a/doc/src/FAQ/FAQ_japanese.html +++ b/doc/src/FAQ/FAQ_japanese.html @@ -7,7 +7,7 @@

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

-原文最終更新日: Mon Mar 18 14:34:57 EST 2002 +原文最終更新日: Fri Apr 26 23:03:46 EDT 2002

現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -94,12 +94,12 @@ http://www.PostgreSQL.org/docs/faq-english.html

操作上の質問

4.1) バイナリ・カーソルと通常カーソルとの違いは何ですか?
-4.2) 最初の数行のみを select するにはどうしますか?
+4.2) 最初の数ロウのみを select するにはどうしますか?
4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか?
-4.4) テーブルから列の削除はどのようにしますか?
-4.5) 行、テーブル、データベースの最大サイズは?
+4.4) テーブルからカラムの削除はどのようにしますか?
+4.5) ロウ、テーブル、データベースの最大サイズは?
4.6) 一般的なテキストファイルからデータを保存するには、データベースのディスク容量はどのくらい必要ですか?
-4.7) データベース内に定義されたテーブルやインデックスをどのようにして見つけ出しますか?
+4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか?
4.8) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか?
4.9) 問い合わせオブティマイザがどのように問い合わせを評価するかを見るにはどうしますか?
4.10) R-tree インデックスとは何ですか?
@@ -116,11 +116,11 @@ http://www.PostgreSQL.org/docs/faq-english.html 4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか?
4.19) どのバージョンの PostgreSQL を走らせているのかを調べるにはどうしますか?
4.20) ラージオブジェクトの操作で、invalid large obj descriptorと出るのはなぜですか?
-4.21) 現在の時刻がデフォルトとなるような列はどのようにつくりますか?
+4.21) 現在の時刻がデフォルトとなるようなカラムはどのようにつくりますか?
4.22) なぜ、INを使う副問い合わせがとても遅いのですか?
4.23) 外部結合(outer join)はどのように実現しますか?
-4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか? - +4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか?
+4.25) 関数で複数のロウまたはカラムを返すにはどうしますか?

PostgreSQLの拡張についての質問

@@ -814,7 +814,7 @@ PostgreSQL Administrator's Gide

postgreSQL プログラムには、デバグと性能測定にとても役に立つ -s-A-t 等のオプションがあります。 -

何という関数がどのくらい実行時間を食っているかを見るために、プロファイリング(プロフィール付き)でコンパイルすることも可能です。そのバックエンドのプロフィール・ファイルは pgsql/data/base/dbname ディレクトリに格納されるでしょう。クライアントのプロフィールはクライアントの現行ディレクトリに置かれるでしょう。 +

何という関数がどのくらい実行時間を食っているかを見るために、プロファイリング(プロフィール付き)でコンパイルすることも可能です。そのバックエンドのプロフィール・ファイルは pgsql/data/base/dbname ディレクトリに格納されるでしょう。クライアントのプロフィールはクライアントの現行ディレクトリに置かれるでしょう。Linux でまともなプロファイリングを行うには -DLINUX_PROFILE でコンパイルする必要があります。

@@ -872,13 +872,13 @@ PostgreSQL

詳述は、オンラインマニュアルで DECLARE を見て下さい。

-

4.2) 最初の数行のみを SELECT するにはどうしますか? +

4.2) 最初の数ロウのみを SELECT するにはどうしますか?

オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。 -

たとえ、欲しいのは最初の数行だけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを考えてみて下さい。 -もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数行だけで評価できるかもしれませんが、でなれば、PostgreSQL は意図した行が生成されるまですべての行を評価しなければならないかもしれません。 +

たとえ、欲しいのは最初の数ロウだけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを考えてみて下さい。 +もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数ロウだけで評価できるかもしれませんが、でなれば、PostgreSQL は意図したロウが生成されるまですべてのロウを評価しなければならないかもしれません。

4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか? @@ -890,31 +890,34 @@ PostgreSQL

-

4.4) テーブルから列の削除はどのようにしますか? +

4.4) テーブルからカラムの削除はどのようにしますか?

ALTER TABLE DROP COLUMN はサポートしていませんが、その代わりにこうします:

-	SELECT ...  -- 削除したい列以外の列をすべて選択します。
+	BEGIN;
+	LOCK TABLE old_table;
+	SELECT ...  -- 削除したいカラム以外のカラムをすべて選択します。
 	INTO TABLE new_table
 	FROM old_table;
 	DROP TABLE old_table;
 	ALTER TABLE new_table RENAME TO old_table;
+	COMMIT;
 
-[訳注:列の追加は ALTER TABLE ADD COLUMN で行えます。] +[訳注:カラムの追加は ALTER TABLE ADD COLUMN で行えます。]

-

4.5) 行、テーブル、データベースの最大サイズは? +

4.5) ロウ、テーブル、データベースの最大サイズは?

制限は以下のとおりです。

 データベースの最大サイズ? 	制限無し (500GB のデータベースも存在します)
 テーブルの最大サイズ?           16TB
-行の最大サイズ?                 7.1以降で制限無し
+ロウの最大サイズ?                 7.1以降で制限無し
 フィールドの最大サイズ?         7.1以降で1GB
 テーブル内での最大ロウ数?       制限無し
 テーブル内での最大カラム数?     カラムの型により250-1600
@@ -940,7 +943,7 @@ PostgreSQL
 ファイルの大きさは次のように約6.4MBと見積もることができます:
 
 
-    36 bytes: 各行のヘッダ(概算)
+    36 bytes: 各ロウのヘッダ(概算)
     24 bytes: 整数(int)フィールドとテキスト(text)フィールド
    + 4 bytes: ページ上のタップルへのポインタ
    ----------------------------------------
@@ -963,18 +966,18 @@ PostgreSQL
 インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。
 
 

-

4.7) データベース内に定義されたテーブルやインデックスをどのようにして見つけ出しますか? +

4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか?

psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。 -

また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。 +

また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。また、pg_ で始まるシステムテーブルにも記述されています。さらに、psql -l はすべてのデータベースをリスト表示します。

4.8) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか?

インデックスは自動的にすべての問い合わせで使われるわけではありません。テー -ブルが最小サイズより大きく、問い合わせでそのわずかなパーセンテージの行を +ブルが最小サイズより大きく、問い合わせでそのわずかなパーセンテージのロウを 選択する時だけ、インデックスは使われます。これはインデックススキャンによ り起こされるランダムなディスクアクセスは、テーブルをストレートに読む順次 走査よりも遅くなることがときどきあるからです。 @@ -982,7 +985,7 @@ PostgreSQL

インデックスを使うかを決定するために、PostgreSQL はテーブルについ ての統計情報を持たなければなりません。この統計情報は、VACUUM ANALYZEまたは、単に ANALYZE を使って収集すること -ができます。統計情報を使ってオブティマイザはテーブルの中に何行あるかを知 +ができます。統計情報を使ってオブティマイザはテーブルの中にあるロウ数を知 り、インデックスを使うべきかのの決定をより正しくできます。統計情報は最適 な結合順や結合方法を決める上でも貴重なものもあります。統計情報の収集は、 テーブルの内容がかわると毎に繰返しなされるべきです。

@@ -1099,14 +1102,14 @@ Type Internal Name Notes "char" char 1 character CHAR(#) bpchar 指定された固定長となるように空白が詰められる VARCHAR(#) varchar 長さの上限の無いテキスト -TEXT text 長さの制限は最大行長による +TEXT text 長さの制限は最大ロウ長による BYTEA bytea 可変長のバイト配列(null-byte safe)

内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。 -

上記の型のうち後の4つの型は "varlena" 型です(すなわち、ディスクの最初の4バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数行に渡って保存されたりして、ディスク上の空間は思ったより小さくなります。 +

上記の型のうち後の4つの型は "varlena" 型です(すなわち、ディスクの最初の4バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数ロウに渡って保存されたりして、ディスク上の空間は思ったより小さくなります。

CHAR()はいつも長さが同じ文字列を保存するのに最適で す。VARCHAR() は可変長の文字列を保存するのに最適ですが、 @@ -1120,7 +1123,7 @@ BYTEA bytea

4.15.1) 通番(serial)/自動増分フィールドはどのようにつくりますか?

-

PostgreSQL は SERIAL データ型をサポートします。列上に通番とインデックスを自動作成します。たとえば、 +

PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自動作成します。たとえば、

 	CREATE TABLE person ( 
@@ -1138,7 +1141,7 @@ BYTEA           bytea           
 	CREATE UNIQUE INDEX person_id_key ON person ( id );
 
通番についてのもっと詳しい情報は、オンラインマニュアルで create_sequence をご覧下さい。 -

また、各行のOIDフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてりロードする必要がある場合は、OIDを温存するためにpg_dump-oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があります。 +

また、各ロウのOIDフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてりロードする必要がある場合は、OIDを温存するためにpg_dump-oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があります。 Bruce Momjian の(http://www.PostgreSQL.org/docs/aw_pgsql_book)の Numbering Rowsの章にありあます。 @@ -1155,7 +1158,7 @@ HREF="#4.16.1">4.16.1 INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');

-そうして、new_id に保存した新しい値を他の問い合わせに(たとえば、person テーブルに対する外部キー(foreign key)のように)使うとよいでしょう。自動的に作られたSEQUENCEオブジェクトの名前は、<table>_<serialcolumn>_seq のようになり、このうち、tableserialcolumn はそれぞれテーブルの名前とSERIAL列の名前です。 +そうして、new_id に保存した新しい値を他の問い合わせに(たとえば、person テーブルに対する外部キー(foreign key)のように)使うとよいでしょう。自動的に作られたSEQUENCEオブジェクトの名前は、<table>_<serialcolumn>_seq のようになり、このうち、tableserialcolumn はそれぞれテーブルの名前とSERIALカラムの名前です。

あるいは、与えられたSERIAL値を、それが既定値として挿入された後で(after)currval() 関数を使って取り出すこともできます。たとえば、 @@ -1188,12 +1191,12 @@ HREF="#4.16.1">4.16.1

4.16) OID とは何ですか? TID とは何ですか?

-

OID とは一意の行 ID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべての行は一意の OID を得ます。initdb で発生される OID はすべて 16384 (backend/access/transam.h から)より小さな値です。initdb 後のすべての OID (ユーザ作成)はそれ以上の値になります。 +

OID とは一意のロウID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべてのロウは一意の OID を得ます。initdb で発生される OID はすべて 16384 (backend/access/transam.h から)より小さな値です。initdb 後のすべての OID (ユーザ作成)はそれ以上の値になります。 既定では、これらすべての OIDは一つのデーブルやデータベース内に留まらず、PostgreSQL インストレーション全体の中で一意です。 -

PostgreSQL はテーブル間の行を結びつけるために、そのシステムテーブル内に OID を使います。この OID は特定のユーザの行を識別するためや結合の中で使われることができます。OID の値を保存するためには OID 型を列に使うことを奨めます。より速くアクセスするために OID フィールドにインデックスを作ることができます。 +

PostgreSQL はテーブル間のロウを結びつけるために、そのシステムテーブル内に OID を使います。この OID は特定のユーザのロウを識別するためや結合の中で使われることができます。OID の値を保存するためには OID 型をカラムに使うことを奨めます。より速くアクセスするために OID フィールドにインデックスを作ることができます。 - OID は、全てのデータベースで使われる中央領域から、全ての新しい行に割り当てられます。OID を他の何かに変えたい、あるいは元の OID もテーブルと一緒にコピーしたいのなら、できなくはありません。 + OID は、全てのデータベースで使われる中央領域から、全ての新しいロウに割り当てられます。OID を他の何かに変えたい、あるいは元の OID もテーブルと一緒にコピーしたいのなら、できなくはありません。

@@ -1210,7 +1213,7 @@ HREF="#4.16.1">4.16.1 
 
 

OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。 -

TID は特定の物理行をそのブロックとオフセット値で識別するために使われます。TID は行が修正されたり再ロードされると変わります。それらの TID は、物理行を指すためにインデックス記載で使われます。 +

TID は特定の物理ロウをそのブロックとオフセット値で識別するために使われます。TID はロウが修正されたり再ロードされると変わります。それらの TID は、物理ロウを指すためにインデックス記載で使われます。

4.17) PostgreSQL で使われるいくつかの用語の意味は何ですか? @@ -1220,8 +1223,8 @@ HREF="#4.16.1">4.16.1
  • テーブル(table)、関係(relation)、クラス(class) -
  • 行(row)、レコード(record)、タップル(tuple) -
  • 列(column)、フィールド(field)、属性(attribute) +
  • ロウ(row)、レコード(record)、タップル(tuple) +
  • カラム(column)、フィールド(field)、属性(attribute)
  • 取得(retrieve)、選択(select)
  • 置換(replace)、更新(update)
  • 追加(append)、挿入(insert) @@ -1263,13 +1266,13 @@ http://www.comptechnews.com/~reaster/dbdesign.html

    ラージ・オブジェクト操作をするときは、前後にBEGIN WORKCOMMITを付ける必要があります。すなわち、lo_open ... lo_closeをはさみ込みます。 -

    現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、lo_openコマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、invalid large obj descriptor(ラージオブジェクトの記述子が不正)となります。それで、もし、トランザクションを使うのを忘れると、(少なくともほとんどの時間)働いていたコードがエラーメッセージを出すのです。 +

    現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、lo_openコマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、invalid large obj descriptor(ラージ・オブジェクトの記述子が不正)となります。それで、もし、トランザクションを使うのを忘れると、(少なくともほとんどの時間)働いていたコードがエラーメッセージを出すのです。

    もし、ODBCのようなクライアントインターフェースをお使いなら、auto-commit offを設定する必要があるかもしれません。

    -

    4.21) 現在の時刻がデフォルトとなるような列はどのようにつくりますか?

    +

    4.21) 現在の時刻がデフォルトとなるようなカラムはどのようにつくりますか?

    CURRENT_TIMESTAMPを使います:

    @@ -1281,7 +1284,7 @@ http://www.comptechnews.com/~reaster/dbdesign.html
     

    4.22) なぜ、INを使う副問い合わせがとても遅いのですか?

    -現在、外部問い合わせの各行について副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。当面はINEXISTSで置き換えることです: +現在、外部問い合わせの各ロウについて副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。当面はINEXISTSで置き換えることです:

     	SELECT *
     	FROM tab
    @@ -1309,7 +1312,7 @@ PostgreSQL 7.1 
     SELECT *
      FROM t1 LEFT OUTER JOIN t2 USING (col);
    -これらの象徴的な問い合わせでは t1.col を t2.col と結合して、t1 の結合されなかった行(t2 と一致しなかった行)も返しています。RIGHT 結合は t2 の結合されなかった行を加えるでしょう。FULL 結合は、一致した行に t1 と t2 からは結合されなかった行を返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。 +これらの象徴的な問い合わせでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。 以前のリリースでは外部結合(outer join)をUNIONNOT IN を使ってシミュレートできます。 たとえば、tab1tab2 を結合するときは、次の問い合わせで二つのテーブルを外部結合します。 @@ -1333,6 +1336,15 @@ PostgreSQL 7.1

    もちろん、クライアントは同時に異なる複数のデータベースへ接続してそこにある情報をマージすることはできます。 +

    +

    4.25) 関数で複数のロウまたはカラムを返すにはどうしますか?

    + +

    もし、PL/pgSQL 関数でrefcursorsを使うと結果の組を返すことができます。 +http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html の +23.7.3.3 節をご覧下さい。

    + +


    PostgreSQLの拡張についての質問

    @@ -1368,7 +1380,7 @@ PostgreSQL 7.1 [訳注: 日本語版の製作については以下の通りです。 - 最終更新日: 2002年04月05日 + 最終更新日: 2002年05月08日 翻訳者: 桑村 潤 (Jun Kuwamura <juk@postgresql.jp>) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): -- cgit v1.2.3