-原文最終更新日: Tue Sep 9 18:42:51 EDT 2003
+原文最終更新日: Mon Mar 29 00:07:11 EST 2004
現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -65,7 +65,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
1.11) PostgreSQLは西暦2000年問題(Y2K)に対応していますか？
1.12) 開発チームにはどのように参加しますか？
1.13) バグレポートはどのように発信しますか？
-1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？
+1.14) 他のDBMSと比べてPostgreSQLはどうなのですか？
1.15) PostgreSQLを資金面で援助するにはどうすればよいですか？
@@ -98,7 +98,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。
-PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。 +
Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。 +この発音を聞きたい人のために、オーディオファイルを http://www.postgresql.org/postgresql.mp3 に用意してあります。
+PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です（このため、今でもときどき "Postgres" と呼ばれることがあります）。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。 -
PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加している開発者達のチームですべて行なわれています。現在の座長は Marc G. Fournier (scrappy@PostgreSQL.org )です。(下記の1.6節に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。 +
PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加している開発者達のチームですべて行なわれています。現在の座長は Marc G. Fournier (scrappy@PostgreSQL.org )です。(下記の1.6節に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。このチームはコミュニティプロジェクトであり、いかなる企業によっても制御を受けません。参加したければ、http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html にある開発者向けのFAQを見てください。 +
Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである POSTGRES はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。 @@ -163,7 +166,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
PostgreSQL Data Base Management System
-Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group +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 @@ -188,14 +191,14 @@ MODIFICATIONS.
POSTGRESQL データベース管理システム - 部分的著作権 (c) 1996-2002, PostgreSQL国際開発チーム + 部分的著作権 (c) 1996-2004, PostgreSQL国際開発チーム 部分的著作権 (c) 1994-6 カリフォルニア大学本校 本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章 およびこれに続く二つの段落が全ての複製に添付されている限りにおい - て、使用、複製、修正および配付の許可を、いかなる目的であっも、無 - 償でかつ同意書無しに行なえることをここに認めます。 + て、使用、複製、修正および配付の許可を、いかなる目的であっても、 + 無償でかつ同意書無しに行なえることをここに認めます。 カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を 含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた @@ -221,14 +224,14 @@ 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 +309,12 @@ href="ftp://ftp.PostgreSQL.org/pub/">ftp://ftp.PostgreSQL.org/pub/ダイジェスト版は、メインリストで受信するメッセージが 30k 程度溜る毎にダイジェスト版リストのメンバーに送付されます。
-バグレポート用のメーリングリストもあります。このリストへの参加は "本文"といっしょに： - バグレポート用のメーリングリストもあります。このリストへの参加は "本文" に： +
@@ -325,8 +332,12 @@ HREF="mailto:bugs-request@PostgreSQL.org">bugs-request@PostgreSQL.org http://www.PostgreSQL.org -+ subscribe + end ++と書いてbugs-request@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.を使って参加できます。 +
[訳注: @@ -359,7 +370,7 @@ UNIX1.7) 最新版はどれですか
-PostgreSQL の最新版はバージョン 7.3.4 です。
+PostgreSQL の最新版はバージョン 7.4.2 です。我々は、6〜8カ月毎にメジャーリリースを行なうことを計画しています。
@@ -501,7 +512,7 @@ href="http://www.PostgreSQL.org/bugs/bugs.php">http://www.PostgreSQL.org/bugs/buそれと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/で、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。
-1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？ +
1.14) 他のDBMSと比べてPostgreSQLはどうなのですか？
@@ -515,7 +526,8 @@ href="http://www.PostgreSQL.org/bugs/bugs.php">http://www.PostgreSQL.org/bugs/bu
既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postmaster 起動に -i フラッグを加え、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。 +
既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postgresql.conf の中の tcpip_sockets を有効にし、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。
操作不能なセマフォも過度のデータベースアクセス中にクラッシュを引き起こすことがあります。
確かにインデックスは問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。 +
確かにインデックスは問い合わせの速度を増します。EXPLAIN ANALYZEコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。
もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中に無い文は、それら自身がそれぞれのトランザクションに入っていると見なされます。いくつかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが減ります。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。
チューニングのオプションがいくつかあります。postmaster を -o -F オプションで起動することによって、fsync() を無効にすることができます。これによって、各トランザクション毎に fsync() でディスクを更新するのを止めさせます。 -
postmaster -B オプションを使ってバックエンド・プロセスにより使われる共有メモリー・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、カーネルの共有メモリー空間の制限値を越えてしまっうために postmaster が走らなくなるでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64 です。 +
postmaster -B オプションを使ってバックエンド・プロセスにより使われる共有メモリー・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、カーネルの共有メモリー空間の制限値を越えてしまうために postmaster が走らなくなるでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64 です。
バックエンドを -S オプションを使って、それぞれのバックエンド・プロセスが一時的な並べ替えによって使うメモリーの最大サイズを増やすこともできます。 その -S の値はキロバイト単位で、既定値は 512 (すなわち、512K)です。 @@ -751,7 +763,7 @@ PostgreSQL Administrator's Gide
これにより PostgreSQL の最上部のディレクトリに server.log ファイルが置かれます。このファイルはサーバーが遭遇した問題やエラーについて有用な情報を含みます。Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オプションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファイルを生成することに注意しなくてはなりません。 -
もし、postmasterが走っていなければ、postgresバックエンドをコマンド行から走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。 +
もし、postmasterが走っていなければ、postgresバックエンドをコマンドラインから走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。
もし、postmasterが走っていれば、あるウィンドウで psqlを開始すると、psql で使われる postgres プロセス @@ -775,7 +787,7 @@ PostgreSQL Administrator's Gide
postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があります。
既定の最大プロセスは32プロセスです。-Nに適切な値を引数にしてpostmasterを再起動するか、PostgreSQL.conf を修正することによって、その値を増やすことができます。 -。既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。 +既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。
もし、-N を 32よりも大きくするのであれば、-Bも既定の64より大きい値に増加させなくてはならないし、-B は少なくとも -N の2倍はなくてはならず、おそらく最高性能を望むならばそれより大きい値が必要なはずです。バックエンドプロセスをたくさんにすると、いろいろなUnixカーネル構成パラメータも増やすことが必要になるかもしれません。 共有メモリー・ブロックの最大値(SHMMAX)、 @@ -825,7 +837,7 @@ PostgreSQL
詳述は、オンラインマニュアルで DECLARE を見て下さい。
-
オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。 @@ -833,7 +845,7 @@ PostgreSQL
たとえ、欲しいのは最初の数ロウだけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを使うことを考えてみて下さい。 もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数ロウだけで評価できるかもしれませんが、でなれば、PostgreSQL は意図したロウが生成されるまですべてのロウを評価しなければならないかもしれません。 -
ランダムな行をSELECTするには、次の文を使います： +
ランダムなロウをSELECTするには、次の文を使います：
SELECT col
FROM tab
@@ -844,11 +856,9 @@ PostgreSQL
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) テーブルからカラムの削除、あるいは、データ型を変更するにはどうしますか？
@@ -886,7 +896,7 @@ PostgreSQL
制限は以下のとおりです。
-データベースの最大サイズ? 制限無し (4 TB のデータベースも存在します)
+データベースの最大サイズ? 制限無し (32 TB のデータベースも存在します)
テーブルの最大サイズ? 32TB
ロウの最大サイズ? 1.6TB
フィールドの最大サイズ? 1GB
@@ -935,7 +945,7 @@ PostgreSQL
インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。
-
NULLはビットマップに保存されていて、それらがわずかにスペースを使います。
+
NULLはビットマップとして保存されていて、それらがわずかにスペースを使います。
@@ -1055,7 +1065,7 @@ Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。
-
大文字と小文字を区別しない等値比較次のように表現できる：
+
大文字と小文字を区別しない等値比較は次のように表現できる：
SELECT *
@@ -1104,13 +1114,13 @@ BYTEA bytea
上記の型のうち最初の４つの型は "varlena" 型です(すなわち、ディスクの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数ロウに渡って保存されたりして、ディスク上の空間は思ったより小さくなります。
-
VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存ためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性ををもちます。
+VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存ためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性をもちます。
4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？
- PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自動作成します。たとえば、
+
PostgreSQL は SERIAL データ型をサポートします。カラム上にシーケンスを自動作成します。たとえば、
CREATE TABLE person (
@@ -1125,7 +1135,6 @@ BYTEA bytea
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 );
@@ -1134,7 +1143,7 @@ BYTEA bytea
通番についてのもっと詳しい情報は、オンラインマニュアルで 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の章にありあます。
@@ -1268,7 +1277,10 @@ href="http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glo
4.22) なぜ、INを使う副問い合わせがとても遅いのですか？
-現在、外部問い合わせの各ロウについて副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。もし、副問い合わせが数行しか返さず、外部問い合わせが沢山の行を返すなら、当面はINをEXISTSで置き換えることです：
+ 7.4 より前のバージョンでは、副問い合わせは、副問い合わせの結果を外部問い合わせの各ロウについて順次走査することによって、外部の問い合わせに結合させられる。
+副問い合わせがわずかなロウしか返さず、外部問い合わせが沢山のロウを返す場合は、INが最も早いです。他の問い合わせを高速化するには、INをEXISTSに置換します:
+
+
SELECT *
FROM tab
@@ -1282,8 +1294,10 @@ href="http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glo
とします。
これが手っ取り早いですが、subcolは索引付きカラムであるべきです。
-ここで示した問題は7.4で修正されます。
-
+
バージョン7.4以降では、INは、通常の問い合わせと同様の洗練されたジョインの技術を実際に使い、EXISTSを使うことを好みます。
+
+
+
4.23) 外部結合(outer join)はどのように実現しますか?
@@ -1334,7 +1348,7 @@ PostgreSQL
4.26)なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができないのでしょうか？
-PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されますが、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一時テーブルアクセスのために使うことです。これで、毎回クエリーのパースし直しを起こすでしょう。
+PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されますが、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一時テーブルアクセスのために使うことです。これで、毎回問い合わせをパースし直すことになるでしょう。
4.27) どのようなリプリケーションオプションを利用できますか?
@@ -1411,7 +1425,7 @@ http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php
[訳注：
日本語版の製作については以下の通りです。
- 最終更新日: 2003年09月20日
+ 最終更新日: 2004年04月28日
翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>)
このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):
--
cgit v1.2.3