-原文最終更新日: Sat Sep 22 20:07:41 EDT 2001 +原文最終更新日: Mon Mar 18 14:34:57 EST 2002
現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
+HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us)
+Maintainer of Japanese Translation: Jun Kuwamura (juk@postgresql.jp)
この文書の最新版は @@ -18,8 +20,9 @@ http://www.PostgreSQL.org/docs/faq-english.html で見ることができます。
-プラットホームに特有の質問については:http://www.PostgreSQL.org/users-lounge/docs/faq.html
+プラットホームに特有の質問については:
+
+ http://www.PostgreSQL.org/users-lounge/docs/faq.html
に回答があります。
@@ -45,7 +48,7 @@ http://www.PostgreSQL.org/docs/faq-english.html
PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。 +
Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。
+PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。
PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加しているインターネット上の開発者チームですべて行なわれています。現在の座長は Marc G. Fournier ( scrappy@PostgreSQL.org )です。(以下に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。
Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである POSTGRES はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。 -
バークレイにおけるこのソフトウェアのもとの名前は Postgres でしたが、SQL の機能が追加された 1995 年にその名前は Postgres95 に変更され、1996 年の終りにその名前は PostgreSQL に変更されました。 - -Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。 +
バークレイにおけるこのソフトウェアのもとの名前は Postgres でしたが、SQL の機能が追加された 1995 年にその名前は Postgres95 に変更され、1996 年の終りにその名前は PostgreSQL に変更されました。
PostgreSQL Data Base Management System
-Portions Copyright (c) 1996-2000, PostgreSQL Global Development Group +Portions Copyright (c) 1996-2002, 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
@@ -183,7 +184,7 @@ MODIFICATIONS.
POSTGRESQL データベース管理システム
- 部分的著作権 (c) 1996-2001, PostgreSQL国際開発チーム
+ 部分的著作権 (c) 1996-2002, PostgreSQL国際開発チーム
部分的著作権 (c) 1994-6 カリフォルニア大学本校
@@ -209,6 +210,10 @@ MODIFICATIONS.
]
+
上記はBSDライセンスで古きオープンソースのライセンスです。ソースコード +がどのように使われようとも制限しません。好ましいことなので、我々もそれを +変えるつもりはありません。
+
MS Windows プラットホーム上で、libpq C ライブラリ、psql、それとその他のインターフェースは コンパイル可能で、バイナリーが走ります。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポートされている Unix プラットホーム上で走るサーバと通信します。 -
Win32 libpq ライブラリと psql を作るために、win31.mak が配布に含まれてます。PostgreSQLは ODBC クライアントとも通信できます。 +
Win32 libpq ライブラリと psql を作るために、win31.mak が配布に含まれてます。PostgreSQLは ODBC クライアントとも通信できます。
EFNet に #PostgreSQL という IRC チャンネルもあります。 -unix コマンドでirc -c '#PostgreSQL' "$USER" irc.phoenix.net/ を使います。
+UNIX コマンドでirc -c '#PostgreSQL' "$USER" irc.phoenix.net を使います。
PostgreSQL の最新版はバージョン 7.2 です。
+ PostgreSQL の最新版はバージョン 7.2.1 です。
我々は、4カ月毎にメジャーリリースを行なうことを計画しています。
@@ -367,17 +373,38 @@ HREF="http://www.PostgreSQL.org/users-lounge/docs/">
http://www.PostgreSQL.org/users-lounge/docs/
でオンラインでも閲覧できます。
- PostgreSQL の本もあります。
-http://www.PostgreSQL.org/docs/awbook.html
+ オンラインで参照できる PostgreSQL の本も2冊あります。http://www.PostgreSQL.org/docs/awbook.html
psql も、型、演算子、関数、集約、その他の情報をお見せする、いくつかの素晴らしい \d コマンドを持ちます。
我々の Web サイトには、もっと沢山の文書があります。
@@ -392,29 +419,45 @@ PostgreSQL
TODO リストに、既知のバグや欠落機能や将来計画についての記述があります。
-
http://www.PostgreSQL.org/docs/awbook.html
-にあるPostgreSQL本で SQL を教えています。
-
-
-素晴らしい学習書には、
-
-http://w3.one.net/~jhoffman/sqltut.htm と
-
-http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM.
-とがあります。その他に、
-"Teach Yourself SQL in 21 Days, Second Edition" が、
-
-http://members.tripod.com/er4ebus/sql/index.htm
-にあります。
+にあるPostgreSQL本で SQL を教えています。
+
+
+その他にも PostgreSQL本として、http://www.commandprompt.com/ppbook
+があります。
+
+素晴らしい手引書は、http://www.intermedia.net/support/sql/sqltut.shtm,
+
+ http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM,
+ そして、http://sqlcourse.com
+にあります。 その他では、 "Teach Yourself SQL in 21 Days, Second Edition" が http://members.tripod.com/er4ebus/sql/index.htmにあります。
多くのユーザに、
The Practical SQL Handbook, Bowman Judith S. et al., Addison-Wesley
が好評です。
その他に、The Complete Reference SQL, Groff et al., McGraw-Hill
のようなのもあります。
+
"bug-template" ファイルの項目を満たして、pgsql-bugs@PostgreSQL.orgに送って下さい。
+ バグを報告する仕方についてのガイドラインと方向づけがあるPostgreSQL BugTool
+ (バグツール)のページを訪れてみて下さい。 その前に http://postgreSQL.orgにある最新の FAQ をチェックして下さい。
それと同時に ftp サイト ftp://ftp.postgreSQL.org/pub/で、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。
-
ソフトウェアを計る方法にはいくつかあります。機能と性能と信頼性とサポートと価格です。
@@ -467,16 +512,13 @@ PostgreSQL Developers
[訳注:
1999年7月23日、日本PostgreSQLユーザー会(にほん ぽすとぐれす ゆーざー かい)、略称JPUGが設立されました。
JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場です。
- 正会員の会費は無料ですが、会員の積極的な貢献が会の運営を助けています。詳しくは、JPUGのWeb サイト:
+ 正会員の会費は無料ですが、協賛会員の会費と会員の積極的な貢献が会の運営を助けています。
+ 詳しくは、JPUG のWeb サイト:
http://www.postgresql.jp/
をご覧ください。会員登録も可能となっています。
1990年代中ごろより、ポストグレスの日本語メーリング・リストを石井 達夫さんが主催しています。詳細は、
@@ -355,7 +361,7 @@ unix
1.7) 最新版はどれですか
-
+ [訳注:
+ （株）SRAと日本ポストグレスユーザー会で翻訳され、
+ 「PostgreSQL オフィシャルマニュアル」
+ として出版されています。
+ ]
+
+
+
[訳注:
- 日本ポストグレスユーザー会のPostgreSQL Book翻訳分科会で、
- 翻訳作業が進行中。
+ 日本ポストグレスユーザー会の 「PostgreSQL Book翻訳分科会」
+ にて翻訳されました。
]
+ および、 http://www.commandprompt.com/ppbook/
+です。
+
+
+ 購入可能な書籍の目録は、http://www.postgresql.org/books/
+ にあります。
+
+ PostgreSQL 技術情報記事も、http://techdocs.postgresql.org/
+ にあります。1.10) SQL はどうすれば学べますか？
+1.10) SQL はどうすれば学べますか？
+ [訳注:
+ 日本ポストグレスユーザー会の 「PostgreSQL Book翻訳分科会」
+ にて翻訳され出版されています。
+ ]
+
+
+
[訳注:
@@ -429,7 +472,7 @@ http://members.tripod.com/er4ebus/sql/index.htm
ではオンラインマニュアルの検索ができます。
丸山不二夫氏のUNIX データベース入門
http://www.wakhok.ac.jp/DB/DB.html
- はオンラインで読むことができます。
+ もオンラインで読むことができます。
]
@@ -446,20 +489,22 @@ PostgreSQL Developers
２番目に、pgsql-hackers と pgsql-patches メーリング・リストを購読(subscribe)します。
３番目に、高品質のパッチをpgsql-patchesに発信します。
-およそ十人ちょっとの人達が、PostgreSQL CVSアーカイブにコミットする権限を持っています。
+およそ十人ちょっとの人達が、PostgreSQL CVSアーカイブにコミットする権限を持っています。
そのそれぞれの人達が沢山の高品質なパッチを発信するので、現在コミッターとなっている人達はそれに追い付くのが大変ですが、我々は彼らがコミットしたパッチは高品質であると確信しています。
1.13) バグレポートはどのように発信しますか？
-1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？
+
1.14) 他のDBMSのと比べてPostgreSQLはどうなのですか？
+PostgreSQLは、トランザクション、副問い合わせ、トリガー、ビュー、外部キー
+整合性参照、および、洗練されたロック機構など、大規模商用
+DBMSが持つ機能をほとんど持っています。さらに PostgreSQLは、ユーザ
+定義型、継承、ルール、それから、ロック競合を縮小するマルチバージョン同時
+性制御など、商用DBMSも持ち合わせないような機能をい
+くつか持ち合わせています。
+
+ +
PostgreSQLは、我々が6年前に始めたとき以来、最高クラスの基盤を +持っています。これはすべて、Marc Fournieさんのおかげで、彼はこの基盤 +を何年にもわたって創造し管理してきました。
+ +質の良い基盤はオープンソース・プロジェクトにとってはとても大切な +もので、前進する勢いを失うプロジェクトの分裂を回避します。 +
+ +もちろん、この基盤は安いものではありません。維持し続けるためには +毎月あるいは一時の経費がかかります。もし、あなたやあなたの会社に、こうし +た努力のための資金を助けるために施すことができるようでしたら、http://www.pgsql.com/pg_goodies +から寄付をお願いします。 + +
また、Webページには PostgreSQL,Inc とありますが、そこの"義援 +(contributions)"アイテムは PostgreSQL プロジェクトをサポートするためだけ +のためで、決して特定の会社のための資金のためではありません。もし、手形 +(check)の方が都合がよければ連絡先の住所へお送り下さい。
+ +-
PsqlODBC と OpenLink ODBC の二つの ODBC ドライバーが利用可能です。 +
PsqlODBC と OpenLink ODBC の二つの ODBC ドライバーが利用可能です。
PsqlODBC は PostgreSQL の配布に含まれています。それについてのさらに詳細な情報は ftp://ftp.PostgreSQL.org/pub/odbc/ @@ -562,13 +630,16 @@ PostgreSQL ] -
OpenLink ODBC は http://www.openlinksw.com/から入手できます。標準的な ODBC クライアント・ソフトウェアで使えますので、支援しているすべてのプラットホーム(Win, Mac, Unix, VMS)から PostgreSQL の ODBC が利用できます。 +
OpenLink ODBC は http://www.openlinksw.com/から入手できます。標準的な ODBC クライアント・ソフトウェアで使えますので、支援しているすべてのプラットホーム(Win, Mac, Unix, VMS)から PostgreSQL の ODBC が利用できます。 -
たぶん彼らは、商用品質のサポートの必要な人々に売っていると思いますが、フリーウェア版はいつでも入手可能のようです。質問は、postgres95@openlink.co.ukにお願いします。 +
たぶん彼らは、商用品質のサポートの必要な人々に売っていると思いますが、 + フリーウェア版はいつでも入手可能のようです。質問は、postgres95@openlink.co.uk + へ送って下さい。
Programmer's Guide -の ODBC の章もご覧ください。 +の ODBC の章もご覧ください。@@ -576,7 +647,7 @@ Programmer's Guide
データベースを裏に持つ Web ページについての素晴らしい紹介が、
-http://www.webtools.com にあります。
+ http://www.webreview.comにあります。
http://www.phone.net/home/mwm/hotlist/にも、もう一つあります。
Web への拡張のためには、PHP が卓越したインターフェースとなっています。http://www.php.net/にあります。 @@ -585,7 +656,7 @@ Programmer's Guide PHPに関する日本語の情報は、2000年4月19日に発足した日本PHPユーザ会のサイト http://www.php.gr.jp/ あるいは、廣川 類さんのサイト - http://www.cityfujisawa.ne.jp/~louis/apps/phpfi/index.html + http://www.geocities.jp/rui_hirokawa/php/ にかなりまとめられています。 前田 充宏さんにより作られたPHP/FIの日本語パッチが様々な人の手を経てPHP3.0.7に適用されました。 現在はPHPJ-DEVにて、 @@ -614,12 +685,12 @@ Programmer's Guide
pgaccess と呼ばれる素晴らしいグラフィカル・ユーザ・インターフェースがあり、この配布と共に出荷されます。Pgaccess にはレポート・ジェネレータもあります。Web ページはhttp://www.flex.ro/pgaccessです。 -
ecpg という C 言語のための埋め込み SQL 問い合わせ言語インターフェースもあります。 +
ecpg という C 言語のための埋め込み SQL 問い合わせ言語インターフェースもあります。
@@ -681,30 +752,29 @@ PostgreSQL Administrator's Gide
もしエラーメッセージがIpcSemaphoreCreate: semget failed (No space left on device)であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策はpostmasterを起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを-Nで使います。より恒久的な解決策は、カーネルのSEMMNS と SEMMNI パラメータを増やすことです。 +
もしエラーメッセージがIpcSemaphoreCreate: semget failed (No space left on device)であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策はpostmasterを起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを-Nで使います。より恒久的な解決策は、カーネルのSEMMNS と SEMMNI パラメータを増やすことです。 + +
操作不能のセマフォも過度なデータベースアクセスの間にクラッシュを +起こす可能性があります。 +
+もし、エラーメッセージがなにか他のものであれば、カーネルの構成でまったくセマフォのサポートをしていないかもしれません。 PostgreSQL Administrator's Gide に共有メモリーとセマフォについての情報の詳細があります。
-
既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postmaster 起動に -i フラッグを加え、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。
操作不能なセマフォも過度のデータベースアクセス中にクラッシュを引き起こすことがあります。
-
既定の設定ではローカルマシンからの unix ドメインのソケット接続しか許しません。TCP/IP 接続を可能にするには postmaster が -i オプションで開始されていて、pgsql/data/pg_hba.conf ファイルに適切なホストの記載が追加されていることを確認してください。 - -
-
確かにインデックスは問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。 -
もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中に無い文は、それら自身がそれぞれのトランザクションに入っていると見なされます。いくつかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが減ります。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。 +
確かにインデックスは問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。 +
もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中に無い文は、それら自身がそれぞれのトランザクションに入っていると見なされます。いくつかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが減ります。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。
チューニングのオプションがいくつかあります。postmaster を -o -F オプションで起動することによって、fsync() を無効にすることができます。これによって、各トランザクション毎に fsync() でディスクを更新するのを止めさせます。 @@ -712,10 +782,10 @@ PostgreSQL Administrator's Gide
バックエンドを -S オプションを使って、それぞれのバックエンド・プロセスが一時的な並べ替えによって使うメモリーの最大サイズを増やすこともできます。 その -S の値はキロバイト単位で、既定値は 512 (すなわち、512K)です。 -
また、CLUSTER コマンドを使って、テーブルのデータをインデックスに合わせるためにグループ化することもできます。詳しくは、オンラインマニュアルで CLUSTER を見て下さい。 +
また、CLUSTER コマンドを使って、テーブルのデータをインデックスに合わせるためにグループ化することもできます。詳しくは、オンラインマニュアルで CLUSTER を見て下さい。
-
PostgreSQL は、デバグのために意味のある、状態情報を報告するいくつかの機能を持ちます。 @@ -730,9 +800,17 @@ PostgreSQL Administrator's Gide
これにより PostgreSQL の最上部のディレクトリに server.log ファイルが置かれます。このファイルはサーバーが遭遇した問題やエラーについて有用な情報を含みます。Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オプションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファイルを生成することに注意しなくてはなりません。 -
もし、postmasterが走っていなければ、postgresバックエンドをコマンド行から走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。 +
もし、postmasterが走っていなければ、postgresバックエンドをコマンド行から走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。 -
もし、postmasterが走っていれば、あるウィンドウでpsqlを開始すると、psql で使われる postgresプロセスのPIDが見つかります。デバッガを使ってpostgresのPIDにアタッチ(attach)します。デバッガの中からブレーク・ポイントをセットし、psqlから問い合わせを発行します。デバグのためにpostgresを始動する場合は、PGOPTIONS="-W n" を設定でき、それから、psql を開始します。これにより、n 秒開始を遅らせるはずなので、デバッガでアタッチして始動を順を追って見ることができます。 +
もし、postmasterが走っていれば、あるウィンドウで +psqlを開始すると、psql で使われる postgres プロセス +のPIDが見つかります。デバッガを使って +postgresのPIDにアタッチ(attach)します。デバッ +ガの中からブレーク・ポイントをセットし、psql から問い合わせを発行 +します。デバグのためにpostgresを始動する場合は、PGOPTIONS="-W n" +を設定でき、それから、psql を開始します。これにより、n 秒 +開始を遅らせるはずなので、デバッガでプロセスにアタッチして、ブレークポイ +ントを設定し、開始から順を追って見てゆくことができます。
postgreSQL プログラムには、デバグと性能測定にとても役に立つ -sや -Aや -t 等のオプションがあります。 @@ -740,20 +818,20 @@ 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)、 -セマフォの最大数(SEMMNSとSEMMNI)、 -プロセスの最大数(NPROC)、 -ユーザ毎の最大プロセス数(MAXUPRC)、 -開くファイルの最大数(NFILEとNINODE +共有メモリー・ブロックの最大値(SHMMAX)、 +セマフォの最大数(SEMMNSとSEMMNI)、 +プロセスの最大数(NPROC)、 +ユーザ毎の最大プロセス数(MAXUPRC)、 +開くファイルの最大数(NFILEとNINODE も確認事項に含まれます。 PostgreSQLに許されるバックエンドのプロセス数が制限されているのは、 システムのリソースを使い果してしまうことを避けるためです。 @@ -761,10 +839,10 @@ PostgreSQL
6.5より前のバージョンのPostgreSQLではバックエンドの最大数は64でしたが、変更するには、include/storage/sinvaladt.hの中のMaxBackendId定数を修正した後に再構築が必要でした。
-
問い合わせ実行モジュールによって生成された一時的なファイルです。例えば、もし ORDER BY 句を満たすためにバックエンドの -S パラメータで許可した値よりも大きなスペースがソートの際に必要だとすると、溢れたデータを保持するために一時的なファイルがいくつか生成されます。 +
問い合わせ実行モジュールによって生成された一時的なファイルです。例えば、もし ORDER BY 句を満たすためにバックエンドの -S パラメータで許可した値よりも大きなスペースがソートの際に必要だとすると、溢れたデータを保持するために一時的なファイルがいくつか生成されます。
一時的なファイルは自動的に消し去られるはずですが、もし、ソートの途中でバックエンドがクラッシュしてしまうとそうはなりません。そのときバックエンドがひとつも走ってなければ、pg_tempNNN.NNファイルを消しても大丈夫です。 @@ -788,40 +866,34 @@ PostgreSQL
-
ロケールの設定を確かめて下さい。PostgreSQL は postmaster プロセスを走らせたユーザーのロケールの設定を使います。postgres とpsql には SET コマンドがあり、データ書式を制御できます。これらをあなたの操作環境に合わせて設定して下さい。 - -
-
詳述は、オンラインマニュアルで DECLARE を見て下さい。 +
詳述は、オンラインマニュアルで DECLARE を見て下さい。
-
オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。 +
オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。 -
たとえ、欲しいのは最初の数行だけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを考えてみて下さい。 -もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数行だけで評価できるかもしれませんが、でなれば、PostgreSQL は意図した行が生成されるまですべての行を評価しなければならないかもしれません。 +
たとえ、欲しいのは最初の数行だけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを考えてみて下さい。 +もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数行だけで評価できるかもしれませんが、でなれば、PostgreSQL は意図した行が生成されるまですべての行を評価しなければならないかもしれません。
-
psqlのソースコードとして書かれた pgsql/src/bin/psql/describe.c ファイルを読むことがその答えです。 -そこには、psqlのバックスラッシュコマンドによる出力のためのSQLコマンドが含まれています。 psql に -E オプションをつけて起動すれば、与えたコマンドを実行するための問い合わせが出力されます。 +そこには、psqlのバックスラッシュコマンドによる出力のためのSQLコマンドが含まれています。 psql に -E オプションをつけて起動すれば、与えたコマンドを実行するための問い合わせが出力されます。
-
ALTER TABLE DROP COLUMN はサポートしていませんが、その代わりにこうします: +
ALTER TABLE DROP COLUMN はサポートしていませんが、その代わりにこうします:
SELECT ... -- 削除したい列以外の列をすべて選択します。 @@ -835,12 +907,12 @@ PostgreSQL-
4.6) 行、テーブル、データベースの最大サイズは？ +
4.5) 行、テーブル、データベースの最大サイズは？
制限は以下のとおりです。
-データベースの最大サイズ? 制限無し (60GB のデータベースも存在します) +データベースの最大サイズ? 制限無し (500GB のデータベースも存在します) テーブルの最大サイズ? 16TB 行の最大サイズ? 7.1以降で制限無し フィールドの最大サイズ? 7.1以降で1GB @@ -857,74 +929,96 @@ PostgreSQL-
4.7) 一般的なテキストファイルからデータを保存するには、データベースのディスク容量はどのくらい必要です？ +
4.6) 一般的なテキストファイルからデータを保存するには、データベースのディスク容量はどのくらい必要です？
-PostgreSQL のデータベースに保存するには、普通のファイルの約6.5倍のディスク容量を必要とします。-
各行に二つずつ整数を持つ 300,000行のファイルを考えてみましょう。ただのファイルでは 2.4MB です。このデータを含む PostgreSQL データベースファイルの大きさは次のように約14MBと見積もることができます： +普通のテキストファイルを PostgreSQL のデータベースに保存するには、最大で約5倍のディスク容量を必要とします。
+ +
例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを考え +てみましょう。テキストの文字列の平均長さを20バイトと仮定すると、フラット +ファイルの大きさは約2.8MB です。このデータを含む PostgreSQL データベース +ファイルの大きさは次のように約6.4MBと見積もることができます：
36 bytes: 各行のヘッダ(概算) - + 8 bytes: 各4バイトの二つの整数(int)フィールド + 24 bytes: 整数(int)フィールドとテキスト(text)フィールド + 4 bytes: ページ上のタップルへのポインタ ---------------------------------------- - 48 bytes per row + 64 bytes per row PostgreSQL のデータページサイズは 8192バイト(8KB)なので: 8192 bytes per page - ------------------- = 171 rows per database page (切り上げ) - 48 bytes per row + ------------------- = 128 rows per database page (切り上げ) + 64 bytes per row - 300000 data rows - -------------------- = 1755 database pages - 171 rows per page + 100000 data rows + -------------------- = 782 database pages + 128 rows per page -1755 database pages * 8192 bytes per page = 14,376,960 bytes (14MB) +782 database pages * 8192 bytes per page = 6,406,144 bytes (6.4 MB)インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。
-
4.8) データベース内に定義されたテーブルやインデックスをどのようにして見つけ出しますか？ +
4.7) データベース内に定義されたテーブルやインデックスをどのようにして見つけ出しますか？
psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。 -
また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。 +
また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。
-
4.9) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか？ +
4.8) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか？
-PostgreSQL は統計情報を自動的には保守しません。統計情報を更新するためには、VACUUM を走らせなくてはなりません。統計情報が更新された後は、オブティマイザがテーブルに何行あるかを知って、インデックスを使うべきかの決定をより良く下します。オブティマイザはテーブルが小さくて連続スキャンの方が速いであろう場合はインデックスを使わないことにご注意下さい。 - -
列特定の最適化統計のためにVACUUM ANALYZEを使います。VACUUM ANALYZEは複雑な複合結合(multi-join)問い合わせのために大切ですので、オブティマイザはそれぞれのテーブルから返される行の数を見積ることができ、特定の結合順序を選びます。バックエンドはそれ自身では列の統計を保持しないので、定期的にそれらを集めるためには VACUUM ANALYZE を走らせなくてはなりません。 - -
普通、インデックスは ORDER BY や結合の操作のためには使われません。ランダムなディスクアクセスはとても遅いので、順次スキャンに続く明示的ソートは、巨大なテーブルの全件をインデックススキャンするよりも高速です。 +インデックスは自動的にすべての問い合わせで使われるわけではありません。テー +ブルが最小サイズより大きく、問い合わせでそのわずかなパーセンテージの行を +選択する時だけ、インデックスは使われます。これはインデックススキャンによ +り起こされるランダムなディスクアクセスは、テーブルをストレートに読む順次 +走査よりも遅くなることがときどきあるからです。 + +
インデックスを使うかを決定するために、PostgreSQL はテーブルについ +ての統計情報を持たなければなりません。この統計情報は、VACUUM +ANALYZEまたは、単に ANALYZE を使って収集すること +ができます。統計情報を使ってオブティマイザはテーブルの中に何行あるかを知 +り、インデックスを使うべきかのの決定をより正しくできます。統計情報は最適 +な結合順や結合方法を決める上でも貴重なものもあります。統計情報の収集は、 +テーブルの内容がかわると毎に繰返しなされるべきです。
+ +インデックスは、通常 ORDER BY や結合を行な +うためには使われません。順次スキャンに続く明示的ソートは、巨大なテーブル +のインデックススキャンよりも普通は高速です。
+ しかし、ORDER BYと組み合わされたLIMIT +は、テーブルの小さな部分を返すためにたびたびインデックスを使うでしょう。 + +LIKE あるいは ~ のようなワイルドカード演算 +子を使うとき、検索の開始が文字列の始めの部分に固定されているときにのみ、 +インデックスが使われます。そういうわけで、インデックスを使うためには、 +LIKE パターンは%で始めないようにして、また、 +~(正規表現)パターンは^ で始めなくてはなりません。 -
LIKE あるいは ~ のようなワイルドカード演算子(wild-card operators)を使うとき、検索の開始が文字列の始めの部分に固定されているときにのみ、インデックスが使われます。 -そういうわけで、インデックスを使うためには、LIKE 検索では%で始めないようにして、また、~(正規表現検索)は^ で始めるようにするべきです。 - -[訳注：強制的にインデックスを使うには - SET enable_seqscan = off を実行します] +[訳注： + 強制的にインデックスを使うには SET enable_seqscan = off を実行します +]
-
4.10) 問い合わせオブティマイザがどのように問い合わせを評価するのかを見るにはどうしますか？ +
4.9) 問い合わせオブティマイザがどのように問い合わせを評価するのかを見るにはどうしますか？
-オンラインマニュアルで EXPLAIN を見て下さい。 +
オンラインマニュアルで EXPLAIN を見て下さい。
-
4.11) R-tree インデックスとは何ですか？
+4.10) R-tree インデックスとは何ですか？
R-tree インデックスは空間的なデータにインデックスを付けるために使われます。ハッシュインデックスでは範囲の検索ができません。また、B-tree インデックスでは、１次元でしか範囲の検索ができません。R-tree インデックスであれば多次元のデータを扱えます。たとえば、もし R-tree インデックスを point 型の属性に付けることができるとするとシステムは、「長方形に囲まれた点をすべて選択する」というような問い合わせに、より効率良く答えられます。
R-Tree の設計の原典となる権威ある論文は:
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." -Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57. +Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
この論文は、Stonebraker 教授の "Readings in Database Systems" でも取り上げられています。 @@ -952,17 +1046,17 @@ Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
-
4.12) 遺伝的問い合わせ最適化とは何ですか？ +
4.11) 遺伝的問い合わせ最適化とは何ですか？
GEQO モジュールは、沢山のテーブルを結合するときに、遺伝的アルゴリズム(GA)で問合わせを高速化します。これにより、しらみつぶしに探索を行なわなくても、大きな結合(join queries)を扱うことができるようになります。
-
4.13) 正規表現での検索や大文字と小文字とを区別しない正規表現検索はどのように実現しますか？大文字と小文字とを区別しない検索のためのインデックスはどのように使いますか？ +
4.12) 正規表現での検索や大文字と小文字とを区別しない正規表現検索はどのように実現しますか？大文字と小文字とを区別しない検索のためのインデックスはどのように使いますか？
-~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 PostgreSQL 7.1 以降では、大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。 +~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 PostgreSQL 7.1 以降では、大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。
大文字と小文字を区別しない等値比較次のように表現できる： @@ -989,13 +1083,14 @@ Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
-
4.14) 問い合わせの中で、フィールドが NULL であることを検出するにはどうしますか？ +
4.13) 問い合わせの中で、フィールドが NULL であることを検出するにはどうしますか？
-IS NULLのカラムを IS NOT NULL で試してみて下さい。 +
カラムを IS NULL と IS NOT NULL +とで試してみます。
-
4.15) 様々な文字型のそれぞれの違いは何ですか？ +
4.14) 様々な文字型のそれぞれの違いは何ですか？
@@ -1005,19 +1100,27 @@ Type Internal Name Notes CHAR(#) bpchar 指定された固定長となるように空白が詰められる VARCHAR(#) varchar 長さの上限の無いテキスト TEXT text 長さの制限は最大行長による -BYTEA bytea 可変長のバイト配列 +BYTEA bytea 可変長のバイト配列(null-byte safe)内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。 -
上記の型のうち後の４つの型は "varlena" 型です(すなわち、ディスクの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数行に渡って保存されたりして、ディスク上の空間は思ったより小さくなります。 +
上記の型のうち後の４つの型は "varlena" 型です(すなわち、ディスクの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数行に渡って保存されたりして、ディスク上の空間は思ったより小さくなります。 + +
CHAR()はいつも長さが同じ文字列を保存するのに最適で +す。VARCHAR() は可変長の文字列を保存するのに最適ですが、 +保存できる文字列の長さに制限があります。TEXT は長さに制限 +の無い文字列の保存ためのもので、最大1ギガバイトです。 +BYTEAは、部分的にNULL のバイトを含むバイナ +リデータを保存するためのものです。
+-
4.16.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？ +
4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？
-PostgreSQL は SERIAL データ型をサポートします。列上に通番とインデックスを自動作成します。たとえば、 +
PostgreSQL は SERIAL データ型をサポートします。列上に通番とインデックスを自動作成します。たとえば、
CREATE TABLE person ( @@ -1035,49 +1138,62 @@ 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の章にありあます。 -
4.16.2) SERIALデータ型に挿入される値は、どうすれば得られますか？ -
- ひとつの方法は、nextval() 関数を使ってその値を挿入する前(before)に SEQUENCE オブジェクトから次の SERIAL 値を取り出し、それから実際に挿入をすることです。 4.16.1 の例で使ったテーブルを使うとすると、次のようになります。 +
4.15.2) SERIALデータ型に挿入される値は、どうすれば得られますか？ +
+ひとつの方法は、nextval() 関数を使ってその値を挿入する +前(before)に SEQUENCE オブジェクトから次の SERIAL 値を取り出し、それから実際に挿入をすることです。4.16.1 の例で使ったテーブルを使うとすると、Perl では +次のようになります。
- $newSerialID = nextval('person_id_seq'); - INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal'); + new_id = output of "SELECT nextval('person_id_seq')" + INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');-そうして、$newSerialID に保存した新しい値を他の問い合わせに(たとえば、person テーブルに対する外部キー(foreign key)のように)使うとよいでしょう。自動的に作られたSEQUENCEオブジェクトの名前は、<table>_<serialcolumn>_seq のようになり、このうち、table と serialcolumn はそれぞれテーブルの名前とSERIAL列の名前です。 +そうして、new_id に保存した新しい値を他の問い合わせに(たとえば、person テーブルに対する外部キー(foreign key)のように)使うとよいでしょう。自動的に作られたSEQUENCEオブジェクトの名前は、<table>_<serialcolumn>_seq のようになり、このうち、table と serialcolumn はそれぞれテーブルの名前とSERIAL列の名前です。-あるいは、与えられたSERIAL値を、それが既定値として挿入された後で(after)、 currval() 関数を使って取り出すこともできます。たとえば、 +あるいは、与えられたSERIAL値を、それが既定値として挿入された後で(after)、 currval() 関数を使って取り出すこともできます。たとえば、
INSERT INTO person (name) VALUES ('Blaise Pascal'); - $newID = currval('person_id_seq'); + new_id = currval('person_id_seq');-最後に、INSERT文から返るOIDを使って、既定値をみつけることもできますが、しかし、これは最も移植性の低いやり方でしょう。PerlのDBIで Edmund Mergl の作った DBD::Pg モジュールを使えば、$sth->execute() の後に $sth->{pg_oid_status} を経由してその OID 値を使えるようにすることはできます。 +最後に、INSERT文から返るOIDを使って、既定値をみつけることもできますが、しかし、これは最も移植性の低いやり方でしょう。PerlのDBIで Edmund Mergl の作った DBD::Pg モジュールを使えば、$sth->execute() の後に $sth->{pg_oid_status} を経由してその OID 値を使えるようにすることはできます。-
4.16.3) 他のユーザとの競合状態を避けるためには、currval() と nextval() は使わないほうがよいのでしょうか？ -
+
4.15.3) 他のユーザとの競合状態を避けるためには、currval() と nextval() は使わないほうがよいのでしょうか？ +
+ +それはありません。Currval() は、すべてのユーザではありませんが、あなたのバックエンドに与えられた現在の値を返します。 -バックエンドが上手に処理するので、競合状態になることは有りません。 +
4.15.4) トランザクションが中断したときにもうい +ちどシーケンス番号が使われないのはなぜですか？シーケンス／SERIALカラムに +空きがあるのはなぜですか？ +
+ +同時性を改善するために、実行中のトランザクションに、必要でト +ランザクションが終了するまでロックされないシーケンス値を与えています。 +このためトランザクションが中断されると番号割り当てにギャップを生じます。 +
-
4.17) OID とは何ですか？ TID とは何ですか？ +
4.16) OID とは何ですか？ TID とは何ですか？
-OID とは一意の行 ID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべての行は一意の OID を得ます。initdb で発生される OID はすべて 16384 (backend/access/transam.h から)より小さな値です。initdb 後のすべての OID (ユーザ作成)はそれ以上の値になります。 -既定では、これらすべての OIDは一つのデーブルやデータベース内に留まらず、PostgreSQL インストレーション全体の中で一意です。 +
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 もテーブルと一緒にコピーしたいのなら、できなくはありません。
@@ -1092,12 +1208,12 @@ BYTEA bytea -->-OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。 +
OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。 -
TID は特定の物理行をそのブロックとオフセット値で識別するために使われます。TID は行が修正されたり再ロードされると変わります。それらの TID は、物理行を指すためにインデックス記載で使われます。 +
TID は特定の物理行をそのブロックとオフセット値で識別するために使われます。TID は行が修正されたり再ロードされると変わります。それらの TID は、物理行を指すためにインデックス記載で使われます。
-
4.18) PostgreSQL で使われるいくつかの用語の意味は何ですか？ +
4.17) PostgreSQL で使われるいくつかの用語の意味は何ですか？
いくつかのソースコードや古い文書の中には、それぞの専門分野の中でもっと一般的に使われる専門用語が使われています。 @@ -1109,7 +1225,7 @@ BYTEA bytea
取得(retrieve)、選択(select) 置換(replace)、更新(update) 追加(append)、挿入(insert) - OID, 連番(serial value) + OID, 連番(serial value) ポータル(portal), カーソル(cursor) 領域変数(range variable)、テーブル名(table name)、テーブル別名(table alias) @@ -1119,7 +1235,7 @@ http://www.comptechnews.com/~reaster/dbdesign.html で見つけられます。 -
4.19) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか？ +
4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか？
もし、7.1 よりも古いバージョンをお使いの場合は、アップデートによってこの問題を @@ -1132,40 +1248,40 @@ http://www.comptechnews.com/~reaster/dbdesign.html
-シェルによって、どちらかひとつが成功するでしょうが、これはプロセスのデータセグメント制限をより高く設定し、たぶん問い合わせが完結するようになるでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスについて適用されます。バックエンドがとても多くのデータを返すためにSQL クライアントで問題が続いているのであれば、クライアントを開始する前にこれを試してみてください。 +シェルによって、どちらかひとつが成功するでしょうが、これはプロセスのデータセグメント制限をより高く設定し、たぶん問い合わせが完結するようになるでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスについて適用されます。バックエンドがとても多くのデータを返すためにSQL クライアントで問題が続いているのであれば、クライアントを開始する前にこれを試してみてください。
-
4.20) どのバージョンの PostgreSQL を走らせているかを調べるにはどうしますか？
+4.19) どのバージョンの PostgreSQL を走らせているかを調べるにはどうしますか？
psql から select version(); をタイプします。
-
4.21) ラージ・オブジェクトの操作でinvalid large obj descriptor を受け取りました。なぜでしょうか？ +
4.20) ラージ・オブジェクトの操作でinvalid large obj descriptor を受け取りました。なぜでしょうか？
ラージ・オブジェクト操作をするときは、前後にBEGIN WORKとCOMMITを付ける必要があります。すなわち、lo_open ... lo_closeをはさみ込みます。
現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、lo_openコマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、invalid large obj descriptor(ラージオブジェクトの記述子が不正)となります。それで、もし、トランザクションを使うのを忘れると、（少なくともほとんどの時間）働いていたコードがエラーメッセージを出すのです。 -
もし、ODBCのようなクライアントインターフェースをお使いなら、auto-commit offを設定する必要があるかもしれません。 +
もし、ODBCのようなクライアントインターフェースをお使いなら、auto-commit offを設定する必要があるかもしれません。
-
4.22) 現在の時刻がデフォルトとなるような列はどのようにつくりますか？
+4.21) 現在の時刻がデフォルトとなるような列はどのようにつくりますか？
-now()を使います: +
CURRENT_TIMESTAMPを使います:
- CREATE TABLE test (x int, modtime timestamp DEFAULT now() ); + CREATE TABLE test (x int, modtime timestamp DEFAULT >CURRENT_TIMESTAMP );-
4.23) なぜ、INを使う副問い合わせがとても遅いのですか？ +
4.22) なぜ、INを使う副問い合わせがとても遅いのですか？
-現在、外部問い合わせの各行について副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。当面はINをEXISTSで置き換えることです： +現在、外部問い合わせの各行について副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。当面はINをEXISTSで置き換えることです：
SELECT * FROM tab @@ -1181,9 +1297,9 @@ http://www.comptechnews.com/~reaster/dbdesign.html この制限は将来のリリースで直したいと思っています。-
4.24) 外部結合(outer join)はどのように実現しますか?
+4.23) 外部結合(outer join)はどのように実現しますか?
-PostgreSQL 7.1 以降ではSQL標準構文を使う外部結合(アウタージョイン)をサポートします。ここに、例題が2つあります。 +PostgreSQL 7.1 以降ではSQL標準構文を使う外部結合(アウタージョイン)をサポートします。ここに、例題が2つあります。
SELECT * @@ -1193,9 +1309,9 @@ 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)をUNION と NOT IN を使ってシミュレートできます。 +以前のリリースでは外部結合(outer join)をUNION と NOT IN を使ってシミュレートできます。 たとえば、tab1 と tab2 を結合するときは、次の問い合わせで二つのテーブルを外部結合します。@@ -1210,7 +1326,7 @@ PostgreSQL 7.1-
4.25) 複数のデータベースを使う問い合わせはどのようにすればできますか？
+4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか？
現行(current)を除いて、データベースへの問い合わせ方法はありません。というのもPostgreSQLがデータベース仕様のシステムカタログを読み込むためで、そこには、たとえそのふりをするだけにしろ、データベースを越えて問い合わせをするすべがありません。 @@ -1243,7 +1359,7 @@ PostgreSQL 7.1
5.4) ソース・ファイルを変更しました。再コンパイルしても変化が見られないのはなぜですか？
-いくつかの Makefile がインクルード・ファイルに対して適切な依存関係を持っていません。make clean をしてからもう一度 make を行なわなくてはなりません。もし、GCC をお使いであれば configure の --enable-depend オプションを使って、コンパイラに依存関係を自動的に調べさせることもできます。 +
いくつかの Makefile がインクルード・ファイルに対して適切な依存関係を持っていません。make clean をしてからもう一度 make を行なわなくてはなりません。もし、GCC をお使いであれば configure の --enable-depend オプションを使って、コンパイラに依存関係を自動的に調べさせることもできます。
@@ -1252,7 +1368,7 @@ PostgreSQL 7.1 [訳注： 日本語版の製作については以下の通りです。 - 最終更新日: 2001年12月10日 + 最終更新日: 2002年04月05日 翻訳者: 桑村 潤 (Jun Kuwamura <juk@postgresql.jp>) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): -- cgit v1.2.3