-原文最終更新日: Sun Jan 9 14:44:04 EST 2005
-
-現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
+
+
+
原文最終更新日: Mon May 9 13:15:04 EDT 2005
+現在の維持管理者: Bruce Momjian (pgman at candle.pha.pa.us)
Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
-この文書の最新版は - - http://www.postgresql.org/files/documentation/faqs/FAQ.html
-で見ることができます。 --プラットホームに特有の質問については: - - http://www.postgresql.org/docs/faq/
-+href="mailto:juk at PostgreSQL.jp">juk at PostgreSQL.jp)+ -
+この文書の最新版は + http://www.postgresql.org/docs/faqs.FAQ.html +で見ることができます。
+プラットホームに特有の質問については: + http://www.postgresql.org/docs/faq/ +
+ +
+に回答があります。+
(以下、訳者による注釈を [訳注： と ] とで囲んで記します。) [訳注： - 日本語版製作についてのメモは最後尾へ移動しました。 - - 日本語版のこの文書は 本家 "Docs" の "Frequently Asked Questions" の - ところに "Japanese FAQ" という見出であります。また、以下のサイトにも - あります。 - http://www.PostgreSQL.jp/wg/jpugdoc/ - http://www.rccm.co.jp/~juk/pgsql/ - http://www.linux.or.jp/JF/ - - この和訳についてお気づきの点は(juk at PostgreSQL.jp)までメールでお寄せ下さい。 + 日本語版の製作については、この文書の最後をごらんください。 - 2005年01月12日 桑村 潤 + 2005年05月18日 桑村 潤 ] -- -
- -一般的な質問
- -1.1) PostgreSQLとは何ですか？ 何と読みますか？
-1.2) PostgreSQLの著作権はどうなってますか？
-1.3) PostgreSQLの動作するUnixプラットホームは？
-1.4) Unix以外の移植版で使えるものは？
-1.5) PostgreSQLはどこから入手できますか？
-1.6) サポートはどこで受けられますか？
-1.7) 最新版はどれですか
-1.8) どのような文書がありますか？
-1.9) 既知のバグや未だ無い機能はどうやって見つけますか？
-1.10) SQLはどうすれば学べますか？
-1.11) PostgreSQLは西暦2000年問題(Y2K)に対応していますか？
-1.12) 開発チームにはどのように参加しますか？
-1.13) バグレポートはどのように発信しますか？
-1.14) 他のDBMSと比べてPostgreSQLはどうなのですか？
-1.15) PostgreSQLを資金面で援助するにはどうすればよいですか？
- - -ユーザー・クライアントの質問
- -2.1) PostgreSQL の ODBC ドライバーはありますか？
-2.2) PostgreSQL を Web ページと連携させるにはどんなツールがありますか？
-2.3) PostgreSQL にグラフィカル・ユーザインターフェイスはありますか？
-2.4) どのような言語で PostgreSQL と通信できすか？
- - -管理上の質問
- -3.1) どのようにすれば /usr/local/pgsql 以外の場所にインストールできますか？
-3.2) postmaster を走らせると、 -Bad System Call とかコア・ダンプしたとのメッセージが出ます。なぜですか？
-3.3) postmaster を走らせようとすると、 -IpcMemoryCreate エラーが出ます。なぜですか？
-3.4) postmasterを走らせようとすると、 -IpcSemaphoreCreate エラーが出ます。なぜですか？
-3.5) 他のホストからの接続はどのように制御しますか？
-3.6) より良い性能を得るためには、データベース・エンジンをどのように調整すれば良いですか？
-3.7) どのようなデバグ機能が使えますか？
-3.8) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？
-3.9) pgsql_tmp ディレクトリの中には何がありますか？
-3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしなくてはならないのはなぜですか？
-3.11) ハードウェアにはどんなコンピュータを使えばよいですか？
- - - -操作上の質問
- -4.1) バイナリ・カーソルと通常カーソルとの違いは何ですか？
-4.2) 最初の数ロウのみを select するにはどうしますか？ ランダムなロウ？
-4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか？
-4.4) テーブルからカラムの削除、あるいは、データ型を変更するにはどうしますか？
-4.5) ロウ、テーブル、データベースの最大サイズは？
-4.6) 一般的なテキストファイルからデータを保存するには、データベースのディスク容量はどのくらい必要ですか？
-4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか？
-4.8) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか？
-4.9) 問い合わせオブティマイザがどのように問い合わせを評価するかを見るにはどうしますか？
-4.10) R-tree インデックスとは何ですか？
-4.11) 遺伝的問い合わせ最適化とは何ですか？
-4.12) 正規表現での検索や大文字と小文字とを区別しない正規表現検索はどのように実現しますか？大文字と小文字とを区別しない検索のためのインデックスはどのように使いますか？
-4.13) 問い合わせの中で、フィールドが NULL であることを検出するにはどうしますか？
-4.14) 色々な文字型のそれぞれの違いは何ですか？
-4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？
-4.15.2) SERIALデータ型に挿入される値は、どうすれば得られますか？
-4.15.3) currval() は他のユーザとの競合状態に陥ることはないですか？
-4.15.4) トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜですか？シーケンス／SERIALカラムに空きがあるのはなぜですか？
-4.16) OID とは何ですか？ TID とは何ですか？
-4.17) PostgreSQL で使われるいくつかの用語の意味は何ですか？
-4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか？
-4.19) どのバージョンの PostgreSQL を走らせているのかを調べるにはどうしますか？
-4.20) ラージオブジェクトの操作で、invalid large obj descriptorと出るのはなぜですか？
-4.21) 現在の時刻がデフォルトとなるようなカラムはどのようにつくりますか？
-4.22) なぜ、INを使う副問い合わせがとても遅いのですか？
-4.23) 外部結合(outer join)はどのように実現しますか?
-4.24) 複数のデータベースを使う問い合わせはどのようにすればできますか？
-4.25) 関数で複数のロウまたはカラムを返すにはどうしますか？
-4.26) なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができないのでしょうか？
-4.27) どのような暗号化オプションを利用できますか?
- -PostgreSQLの拡張についての質問
- -5.1) 自分で書いたユーザ定義関数を psql の中で実行するとコア・ダンプしてしまうのはなぜですか？
-5.2) PostgreSQL 用に書いたちょっと素敵な新しい型や関数を提供してプロジェクトに貢献したいのですが？
-5.3) タプルを返す C言語の関数はどのように書きますか？
-5.4) ソース・ファイルを変更しました。再コンパイルしても変化が見られないのはなぜですか？
-
-一般的な質問
- -1.1) PostgreSQL とは何ですか？ 何と読みますか？
- -PostgreSQLはPost-Gres-Q-L(ポスト - グレス - キュー - エル) と発音します。
-PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です（このため、今でもときどき "Postgres" と呼ばれることがあります）。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。 -
- -PostgreSQL の開発は、PostgreSQL 開発メーリングリストに参加している開発者達のチームですべて行なわれています。現在の座長は Marc G. Fournier (scrappy@PostgreSQL.org )です。(下記の1.6節に参加の仕方があります。)現在、このチームが PostgreSQL 開発のすべての面倒をみています。このチームはコミュニティプロジェクトであり、いかなる企業によっても制御を受けません。参加したければ、 - http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html -にある開発者向けのFAQを見てください。 -
+
Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである Postgres はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。 -
+PostgreSQLはPost-Gres-Q-L(ポスト - グレス - キュー - エル) + と発音します。
また、単純に Postgres とも呼ばれます。 + +PostgreSQL はオブジェクト-リレーショナルデータベースシステムで、 + 伝統的な商用データベースシステムに、次世代DBMSシステ + ムに見られるような改良が施された特徴を有します。PostgreSQLは、無料で + 完全なソースコードを手に入れることができます。
+ +PostgreSQL の開発は、ほとんどが、世界中にひろがったボランティアの + 開発者によって、インターネットを通したコミュニケーションによって行わ + れています。コミュニティによるプロジェクトであるため、どの企業の制御 + もうけません。開発に参加したければ、 + http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html + にある開発者のFAQを見てください。 +
-バークレイにおけるこのソフトウェアのもとの名前は Postgres でしたが、SQL の機能が追加された 1995 年にその名前は Postgres95 に変更され、1996 年の終りにその名前は PostgreSQL に変更されました。 -
+PostgreSQL は下記の著作権に従います。
-PostgreSQL は下記の著作権に従います。 -
-+-[訳注： 正文は英語です。参考として、訳文を併記掲載します。 ] ---PostgreSQL Data Base Management System
--Portions Copyright (c) 1996-2005, 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 -documentation for any purpose, without fee, and without a written -agreement is hereby granted, provided that the above copyright notice -and this paragraph and the following two paragraphs appear in all -copies.
--IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY -FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, -INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS -DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF -THE POSSIBILITY OF SUCH DAMAGE.
--THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, -INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY -AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER -IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO -OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR -MODIFICATIONS.
- -++PostgreSQL Data Base Management System
++ Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group + Portions Copyright (c) 1994-1996 Regents of the University of California
++ Permission to use, copy, modify, and distribute this software and its + documentation for any purpose, without fee, and without a written + agreement is hereby granted, provided that the above copyright notice + and this paragraph and the following two paragraphs appear in all + copies.
++ IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY + FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, + INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS + DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF + THE POSSIBILITY OF SUCH DAMAGE.
++ THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY + AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER + IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO + OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR + MODIFICATIONS.
+ +POSTGRESQL データベース管理システム - 部分的著作権 (c) 1996-2004, PostgreSQL国際開発チーム - 部分的著作権 (c) 1994-6 カリフォルニア大学本校 + 部分的著作権 (c) 1996-2005, PostgreSQL国際開発チーム + 部分的著作権 (c) 1994-1996 カリフォルニア大学本校 本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章 @@ -212,1248 +182,991 @@ MODIFICATIONS. 著作権に関する正文は上記の英語による表記です。日本語訳はあくまで 参考です。 ] -+
上記はBSDライセンスで古きオープンソースのライセンスです。ソースコード -がどのように使われようとも制限しません。好ましいことなので、我々もそれを -変えるつもりはありません。
+一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働さ + せられるはずです。リリースの時点で実際にテストを行なったことの報告が + なされたプラットホームについてはインストール手引書に列挙してあります。 +
--一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働させられるはずです。リリースの時点で実際にテストを行なったことの報告がなされたプラットホームについてはインストール手引書に列挙してあります。
+PostgreSQL は、Win2000, WinXP, そして、Win2003 のような Microsoft + Windows NTベースのオペレーティングシステムで、ネイティブに走ります。 + あらかじめパッケージにされたインストーラが + http://pgfoundry.org/projects/pginstaller + にあり、利用できます。MSDOSベースのWindowsのバージョン(Win95, Win98, + WinMe)では、Cygwinを使って PostgreSQL を走らせることができます。
-バージョン8.0になり、PostgreSQL は、Win2000, WinXP, Win2003などの Microsoft Windows NTベースのオペレーティングシステムでネイティブに走るようになりました。 -パッケージになったインストーラが、http://pgfoundry.org/projects/pginstallerから入手できます。 -Windows (Win95, Win98, WinMe)など、MSDOSベースのバージョンでは、Cygwin を使ってPostgreSQLを走らせることができます。 -
- -
+
[訳注
pgInstaller の入手はFTPミラーサイトの win32 ディレクトリからも可能です。
http://www.postgresql.org/mirrors-ftp.html
+
+ 詳しくは、次の Windwos版に関するFAQの和訳をごらんください。
+ http://www.postgresql.jp/wg/jpugdoc/FAQ_windows.ja.html
]
-
+
- 次のサイトに Novell Netware 6 への移植もあります。 +
次のサイトに Novell Netware 6 への移植版もあります。 http://forge.novell.com また、OS/2 (eComStation) バージョンは、 - http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2Fにあります。
-PostgreSQL の大元の anonymous ftp サイトは -ftp://ftp.PostgreSQL.org/pub/ -です。 -ミラーサイトについては、我々のメイン Web ページをご覧下さい。
- -- [訳注: - - 以下は日本のミラーサイトです: - - Japan: ftp://ftp.jp.postgresql.org/ - Japan: ftp://mirror.nucba.ac.jp/mirror/PostgreSQL/pub/ - Japan: ftp://ring.ip-kyoto.ad.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.crl.go.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.saitama-u.ac.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.astem.or.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.exp.fujixerox.co.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.jah.ne.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.etl.go.jp.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.asahi-net.or.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.so-net.ne.jp/pub/misc/db/PostgreSQL/ - Japan: ftp://ring.aist.go.jp/pub/misc/db/PostgreSQL/ - ] -- -
主要なメーリング・リストは: pgsql-general@PostgreSQL.orgです。PostgreSQL に関することであれば議論ができます。このリストへの参加は、電子メールの本文(Subject 行ではありません)に次の２行を書いて、
-- subscribe - end -- -
pgsql-general-request@PostgreSQL.org へ送って下さい。
- -ダイジェスト版のメーリング・リストもあります。このリストへの参加は "本文"に：
-- subscribe - end -- -
と書いて pgsql-general-digest-request@PostgreSQL.org へ電子メールを送って下さい。
- -ダイジェスト版は、メインリストで受信するメッセージが 30k 程度溜る毎にダイジェスト版リストのメンバーに送付されます。
- -バグレポート用のメーリングリストもあります。このリストへの参加は "本文" に： -
-- subscribe - end --
-と書いてpgsql-bugs-request@PostgreSQL.org - -へ電子メールを送って下さい。
- -開発者の議論のためのメーリングリストも利用できます。このリストへの参加は電子メールの本文に： -
-- subscribe - end -- -
と書いて、pgsql-hackers-request@PostgreSQL.orgへ電子メールを送って下さい。
- -PostgreSQL についてもっと詳しく知りたければ、次の PostgreSQL WWWホームページからたどれます：
-- --
メジャーなIRC チャンネルは、Freenode (irc.freenode.net)の
-#PostgreSQL というチャンネルです。
-UNIX コマンドで、
- irc -c '#PostgreSQL' "$USER" irc.freenode.net.
-を使って参加できます。
-同じネットワークに、スペイン語のチャンネル(#postgresql-es)もあ
-り、フランス語のチャンネル(#postgresqlfr)もあります。
-EFNetにもPostgreSQLチャンネルがあります。
-
+ "http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2F"> + http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2Fにあります。 ++
+ + +1.4) PostgreSQL はどこから入手できますか？
+ +Webブラウザ経由だと、 + http://www.postgresql.org/ftp/、それから、ftp経由だと、 + + ftp://ftp.PostgreSQL.org/pub/ を使います。
+ + +1.5) サポートはどこで受けられますか？
+ +PostgreSQL コミュニティは多くのユーザのために、電子メール経由の支 + 援を提供しています。電子メールリストをサブスクライブするためのメイン + となるウェブサイトは + + http://www.postgresql.org/community/lists/です。これから、始める + のであれば general または、bugs といったリストがよいで + しょう。
+ +The major IRC channel is #postgresql on Freenode + (irc.freenode.net). To connect you can use the Unix + program
+ +irc -c '#postgresql' "$USER" irc.freenode.net+ or use any other IRC clients. A Spanish one also exists + on the same network, (#postgresql-es), and a French one, + (#postgresqlfr). There is also a PostgreSQL channel on EFNet.メジャーなIRC チャンネルは、Freenode (irc.freenode.net)の + #postgresql というチャンネルです。UNIX コマンドでは、 +
+ + +irc -c '#PostgreSQL' "$USER" irc.freenode.netを使って + 参加できます。同じネットワークに、スペイン語のチャンネル + (#postgresql-es)もあり、フランス語のチャンネル + (#postgresqlfr)もあります。EFNetにもPostgreSQLチャンネルがあ + ります。+
[訳注: 1999年7月23日、日本ポストグレスユーザー会、略称JPUGが設立されました。 JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。 (2003年5月17日、「日本PostgreSQLユーザ会」に名称を改めました。) 正会員の会費は無料ですが、協賛会員の会費と会員の積極的な貢献が会の運営を助けています。 詳しくは、JPUG のWeb サイト: - http://www.PostgreSQL.jp/ - をご覧ください。会員登録も可能となっています。 + http://www.PostgreSQL.jp/ + をごらんください。会員登録も可能となっています。 日本語のIRCチャンネル '#PostgreSQL*jp' も存在します。 -+
商用サポート会社のリストは + http://techdocs.postgresql.org/companies.phpにあります。
-商用サポート会社のリストはhttp://techdocs.postgresql.org/companies.phpにあります。
+-PostgreSQL の最新版はバージョン 7.4.6 です。
--我々は、6〜8カ月毎にメジャーリリースを行なうことを計画しています。
++ http://www.postgresql.org/support/submitbug + のPostgreSQL バグフォームを訪れてください。 バグレポートを提出する仕方 + についての手引と指針があります。
+それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/ + で、最新バージョンの PostgreSQL を探してみてください。
-配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュアル・ページ)およびいくつかの小さなテスト例題が含まれます。/doc ディレクトリをご覧下さい。また、マニュアルは、http://www.ca.PostgreSQL.org/docs/でオンラインでも閲覧できます。
+- [訳注: - （株）SRAと日本PostgreSQLユーザ会で翻訳され、 - 「PostgreSQL オフィシャルマニュアル」 - として出版されています。 - ] -+
PostgreSQL の最新版はバージョン 8.0.3 です。
+我々は、1年毎にメジャーリリースを行ない、数ヵ月ごとのマイナーリリー + スをを計画しています。
-オンラインで参照できる PostgreSQL の本も2冊あります。http://www.PostgreSQL.org/docs/awbook.html -
-+- PostgreSQL 技術情報記事も、http://techdocs.PostgreSQL.org/ - にあります。 -1.8) どのような文書がありますか？
+ +配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュ + アル・ページ)およびいくつかの小さなテスト例題が含まれます。 + /docディレクトリをごらんください。また、マニュアルは、 + http://www.PostgreSQL.org/docs/でオンラインでも閲覧できます。 +
+ + +[訳注: - 日本ポストグレスユーザー会の 「PostgreSQL Book翻訳分科会」 - にて翻訳されました。 + JPUG 文書・書籍関連分科会で翻訳されたマニュアルもあります。 + + http://www.postgresql.jp/document/pg803doc/ + インプレスから、 + + PostgreSQLオフィシャルマニュアルとして出版されています。 + ] --- および、 http://www.commandprompt.com/ppbook/ -です。 - - 購入可能な書籍の目録は、http://techdocs.PostgreSQL.org/techdocs/bookreviews.php - にあります。 +
+ +
オンラインで参照できる PostgreSQL の本も2冊あります。
+ http://www.PostgreSQL.org/docs/awbook.html
+
+
[訳注:
- 和訳文書は、日本ポストグレスユーザー会のhttp://www.postgresql.jp/document/
- をごらん下さい。
+ JPUG「PostgreSQL Book翻訳分科会」
+ で翻訳され、ピアソンから
+ 「はじめてのPostgreSQL」として出版されました。
]
-
コマンドラインのクライアントプログラムpsql も、型、演算子、関数、集約、その他の情報をお見せする、いくつかの素晴らしい \d コマンドを持ちます。 -- \? を使うと利用可能なコマンドが表示されます。 -
- -我々の Web サイトには、もっと沢山の文書があります。
- - --PostgreSQLは拡張されたSQL-92のサブセットをサポートします。 -我々のページの -TODO -リストに、既知のバグや欠落機能や将来計画についての記述があります。
- -- -http://www.PostgreSQL.org/docs/awbook.html -にあるPostgreSQL本で SQL を教えています。 -
-++ + および、 + http://www.commandprompt.com/ppbook/です。 + +
[訳注:
- 日本ポストグレスユーザー会の 「PostgreSQL Book翻訳分科会」
- にて翻訳され出版されています。
+ 邦訳は「実践 PostgreSQL」
+ がオライリーから出版されています。
]
-
+
+
+ 購入可能な書籍の目録は、http://techdocs.PostgreSQL.org/techdocs/bookreviews.php
+ にあります。
--その他にも PostgreSQL本として、http://www.commandprompt.com/ppbook -があります。 + PostgreSQL 技術情報記事も、http://techdocs.PostgreSQL.org/ + にあります。
-素晴らしい手引書は、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 -のようなのもあります。 -
- -++ -[訳注: - 石井達夫氏による日本語の参考文献の紹介ページ - http://www.SRA.co.jp/people/t-ishii/PostgreSQL/doc-jp/index.html - があります。 - 近藤直文氏の「初心者向のＤＢ設計入門・ＳＱＬ入門参考書紹介」のコーナー - http://www.shonan.ne.jp/~nkon/ipsql/books_SQL.html - があります(やや古い2000年版)。 - 堀田倫英氏の「PostgreSQL日本語マニュアル」 - http://www.net-newbie.com/ - ではオンラインマニュアルの検索ができます。 - 丸山不二夫氏のUNIX データベース入門 - http://www.wakhok.ac.jp/DB/DB.html - もオンラインで読むことができます。 + 日本語の書籍等についてはは、日本PostgreSQLユーザ会の、http://www.postgresql.jp/PostgreSQL/references.html + もごらんください。 ] -- -1.11) PostgreSQLは西暦2000年問題(Y2K)に対応していますか？ -
--対応してます。西暦2000年より後の日付も、紀元前2000年より前の日付も、簡単に扱えます。
- -1.12) 開発チームにはどのように参加しますか？
-
--まず最初(１番目)に、最新のソースをダウンロードし、我々の Web サイトか配布に含まれているPostgreSQL Developersの文書を読みます。 -２番目に、pgsql-hackers と pgsql-patches メーリング・リストを購読(subscribe)します。 -３番目に、高品質のパッチをpgsql-patchesに発信します。
--およそ十人ちょっとの人達が、PostgreSQL CVSアーカイブにコミットする権限を持っています。 -そのそれぞれの人達が沢山の高品質なパッチを発信するので、現在コミッターとなっている人達はそれに追い付くのが大変ですが、我々は彼らがコミットしたパッチは高品質であると確信しています。
- -1.13) バグレポートはどのように発信しますか？ -
- -- http://www.postgresql.org/support/submitbug -のPostgreSQL バグフォームを訪れて下さい。 バグレポートを提出する仕方についての手引と指針があります。
+
それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/で、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。
+コマンドラインのクライアントプログラムpsql も、型、演算子、 + 関数、集約、その他の情報をお見せする、いくつかの素晴らしい \d コマン + ドを持ちます。 - \? を使うと利用可能なコマンドが表示されます。
-我々の Web サイトには、さらに沢山の文書があります。
--ソフトウェアを計る方法にはいくつかあります。機能と性能と信頼性とサポートと価格です。
-PostgreSQLは拡張されたSQL-92のサブセットをサポート + します。我々のページの TODO リストに、 + 既知のバグや欠落機能や将来計画についての記述があります。
-まず、 上記で述べた PostgreSQL についての本を読むことを検討してください。 + もうひとつは、 "Teach Yourself SQL in 21 Days, Second Edition" + at 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 も好評です。
-素晴らしい手引書は、http://www.intermedia.net/support/sql/sqltut.shtm, + + http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, + そして、http://sqlcourse.com + にあります。
-PostgreSQLは、我々が始めた 1996年以来、最高クラスの情報基盤を持ってい -ます。これはすべて、Marc Fournieさんのおかげで、彼はこの基盤を創り出し、何年にもわたって管理してきました。
-質の良い基盤は、オープンソース・プロジェクトにとってはとても大切なもので、プロジェクトが前進する勢いを失って分裂するのを回避します。
+
+
+ [訳注:
+ 石井達夫氏による日本語の参考文献の紹介ページ
+ http://www.SRA.co.jp/people/t-ishii/PostgreSQL/doc-jp/index.html
+ があります。
+ 近藤直文氏の「初心者向のＤＢ設計入門・ＳＱＬ入門参考書紹介」のコーナー
+ http://www.shonan.ne.jp/~nkon/ipsql/books_SQL.html
+ があります(やや古い2000年版)。
+ 堀田倫英氏の「PostgreSQL日本語マニュアル」
+ http://www.net-newbie.com/
+ ではオンラインマニュアルの検索ができます。
+ 丸山不二夫氏のUNIX データベース入門
+ http://www.wakhok.ac.jp/DB/DB.html
+ もオンラインで読むことができます。
+ Nikkei BP IT Pro にある石井達夫氏の PostgreSQL ウォッチ
+ では毎回新しい情報をとりあげています。
+ ]
+
+
+ （開発者向けの）Developer's FAQをごらんください。 + + +
ソフトウェアを計る方法にはいくつかあります。機能と性能と信頼性と + サポートと価格です。
+ +PostgreSQLの門番、中央委員会、あるいは、コントロールをする会社を + 探そうとしても、諦めざるをえず ---- 存在しないのです。我々は、中心 + となるコミッティとCVSコミッタを持ちますが、これらのグループはコン + トロールするためというよりも、管理上のものです。ここでは、プロジェ + クトは、だれでも参加ができる開発者とユーザのコミュニティにより方向 + 付けられます。読者がやらなければならないことは、メーリングリストを + サブスクライブして、議論に 参加することです。（Developer's + FAQには、PostgreSQL開発に加わり方についての情報があります。）
+ + +PostgreSQL のインストールに含まれる物はCと組込み + Cのインターフェースだけです。その他のインターフェース + は独立したプロジェクトで、別々にダウンロードされます。分かれることで、 + それぞれの開発チームが独自のリリーススケジュールを持つことが許されま + す。
+ +PHP のようないくつかのプログラミング言語は、 + PostgreSQLのインターフェースを含んでいます。Perl, TCL, + Python, そして、そのほかの利用可能な言語のインターフェースは、 + http://gborg.postgresql.org + の Drivers/Interfaces の節の中とインターネットの検索でみつけ + られます。 +
+ + + データベースを裏に持つ Web ページについての素晴らしい紹介が、
+ http://www.webreview.comにあります。
Web への拡張のためには、PHP(http://www.php.net/) + が卓越したインターフェイスとなっています。
+ ++ [訳注: + PHPに関する日本語の情報は、2000年4月19日に発足した日本PHPユーザ会のサイト + http://www.php.gr.jp/ + あるいは、廣川 類さんのサイト + http://www.geocities.jp/rui_hirokawa/php/ + にかなりまとめられています。 + ] +-
もちろん、この基盤は安いものではありません。維持し続けるためには毎月あるいは一時的に経費がかかります。もし、あなたやあなたの会社に、こうした努力のための資金の援助を施すことができるようでしたら、http://store.pgsql.com/shopping/から寄付をお願いします。 -
+処理が複雑な場合、多くの人は Perl インターフェイスと CGI.pm か + mod_perl を使います。
-また、Webページには PostgreSQL,Inc とありますが、そこの "貢献(contributions)"という項目は、 PostgreSQL プロジェクトを支援するだけのためで、決して特定の会社のための資金ではありません。もし、小切手(check)の方が都合よければ連絡先の住所へお送り下さい。
-さらに、PostgreSQLを使った成功事例をお持ちであれば、ぜひ、われわれの -事例紹介リスト - pgsql-advocacy@postgresql.org -へお送りください。 -
+もちろん、あります。 + 詳細は、http://techdocs.postgresql.org/guides/GUITools + をごらんください。
-PsqlODBC と OpenLink ODBC の二つの ODBC ドライバーが利用可能です。
-PsqlODBC は次の場所からダウンロードできます。 - - http://gborg.postgresql.org/project/psqlodbc/projdisplay.php -
+OpenLink ODBC は http://www.openlinksw.com/から入手できます。標準的な ODBC クライアント・ソフトウェアで使えますので、支援しているすべてのプラットホーム(Win, Mac, Unix, VMS)から PostgreSQL の ODBC が利用できます。 -
+たぶん彼らは、商用品質のサポートの必要な人々に売っていると思いますが、 - フリーウェア版はいつでも入手可能のようです。質問は、postgres95@openlink.co.uk - へ送って下さい。
-- -Programmer's Guide -の ODBC の章もご覧ください。 -
+簡単な方法は、 configure を走らせるときに --prefix オプショ + ンを指定することです。
- データベースを裏に持つ Web ページについての素晴らしい紹介が、
- http://www.webreview.comにあります。
Web への拡張のためには、PHP が卓越したインターフェイスとなっています。http://www.php.net/にあります。 -
-- [訳注: - PHPに関する日本語の情報は、2000年4月19日に発足した日本PHPユーザ会のサイト - http://www.php.gr.jp/ - あるいは、廣川 類さんのサイト - http://www.geocities.jp/rui_hirokawa/php/ - にかなりまとめられています。 - ] -+
処理が複雑な場合、多くの人は Perl インターフェイスと CGI.pm か mod_perl を使います。 -
+既定値では、PostgreSQL は Unix ドメインソケット、または、TCP/IP接 + 続のローカルマシンからの接続しか許しません。postgresql.conf の中の + listen_addresses を修正し、かつ、$PGDATA/pg_hba.conf + ファイルを適切に直して、ホスト主導型認証を有効にしないかぎりは、他 + のマシンからは接続できないでしょう。
-- [訳注: - WDB は、Web から DataBase への Perl の Interface です。 - wdb-p95 へのリンクは切れてしまっています。おそらく、Perl DBI 経由で DBD::Pg の利用が可能と思われます。 - 現在、WDBI という名前になっているもの - http://www.egroups.com/list/wdb-users/ - と、WDBの名前のままのもの - http://www.i-con.dk/wdb/ - とがあります。その経緯はよくわかりません。 - ] -- -
もちろん、PostgreSQL へのグラフィカルインターフェイスがいくつかあります。 -その中にPgAccess http://www.pgaccess.org -も含まれます。 -PgAdmin III (http://www.pgadmin.org)もあります。 -RHDB Admin (http://sources.redhat.com/rhdb/ -)、TORA (http://www.globecom.net/tora/ - (部分的に商用)) -および、 Rekall ( - http://www.thekompany.com/products/rekall/, proprietary)もありま -す。 -PhpPgAdmin ( - http://phppgadmin.sourceforge.net/ ) はPostgreSQLへのWebベースの -インターフェイスを提供します。 -
- -より詳細なリストについては、http://techdocs.postgresql.org/guides/GUITools - をご覧ください。
- -人気のあるほとんどの言語はPostgreSQLへのインターフェイスを持っています。 -あなたが使うプログラミング言語の拡張モジュールのリストを覗いてみてください。 -
- -以下のインターフェイスはPostgreSQLの配布に含まれています。 -
- -その他の利用可能なインターフェイスは -http://gborg.postgresql.org -のDrivers/Interfacesのセクションにあります。 -
- -- [訳注： - 永安悟史さんは Palm 版の libpq を開発されました。 - http://www.snaga.org/libpq/ - ] --
性能改善の可能性のありそうな主な領域が3つあります：
+サーバ構成変数には多くの log_* があり、クエリとプロ
+ セスの統計を出力することができ、デバグと性能計測にとても便利です。
既定での制限である 100 のデータベースセッションに達してしまって + います。postmasterが同時接続できるバックエンドプロセスの制限 + 数を増やす必要があります。postgresql.conf の中の + max_connections の値を変更して postmasterを再起動する + ことで可能になります。
+ +PostgreSQLチームはマイナーリリースでは小さな変更しか行ないません + ので、7.4.0 から 7.4.1 へのアップグレードにはダンプとリストアの必要は + ありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような) + では、システムテーブルやデータファイルの内部フォーマットの変更をしば + しば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファ + イルのための後方互換性を維持することができません。ダンプは汎用フォー + マットでデータを出力し、それを新しい内部フォーマットに読み込むことが + できます。
+ +PCハードウェアはほとんど互換性がありますので、ほとんどの人は、す + べてのPCハードウェアが同じ品質だと思い込む傾向があります。しかし、そ + れは間違いです。ECC RAM、SCSI、および、高品質マザーボードは、安いハー + ドウェアに比べると、より信頼性が高く、より性能も良いのです。 + PostgreSQL はほとんどのハードウェアで稼働しますが、信頼性や性能が重 + 要な場合は、ハードウェアのオプションを研究することが賢明です。メーリ + ングリストでもハードウェアオプションとトレードオフについて議論するこ + とができます。
+ +たったの数行のロウを取り出すために、何行必要かがわかれば、 + SELECT のときに LIMIT を使います。 + ORDER BYにインデックスがマッチした場合、まったくクエ + リが実行されないこともあります。SELECT のときに何行 + が必要かを知らなければ、カーソルを使いFETCHします。
+ +ランダムロウをSELECTするには、次の文を使います： +
+ SELECT col + FROM tab + ORDER BY random() + LIMIT 1; +-
簡単な方法は、 configure を走らせるときに --prefix オプションを指定することです。 -
+psql の中で \dtコマンドをを使ってテーブルを見ることができ + ます。psqlの中で \? を使って、コマンドの全リストを調べることができま + す。一方で、psql のソースコードで、バックスラッシュコマンドを + 出力する pgsql/src/bin/psql/describe.c ファイルを読むこともで + きます。その中には、 SQL コマンドを生成する部分も含ま + れます。また、 -E オプションを付けて psql を開始すると、 + 入力されたコマンドを実行するためのクエリを印字出力するようになります。 + PostgreSQLは SQL 準拠の INFORMATION SCHEMA インター + フェースを提供しますので、データベースについての情報を問い合わせるこ + ともできます。
-さまざまな問題が考えられますが、まず最初にあなたのカーネルに System V IPC の拡張がインストールされているかを確認して見てください。PostgreSQL はカーネルによる共有メモリーとセマフォのサポートを必要とします。 +
pg_ で始まるシステムテーブルでもこれらを記述することができ + ます。
+ +psql -lを使うと全てのデータベースをリスとします。
- -それと、pgsql/src/tutorial/syscat.source を試してみてくだ + さい。そこには、データベースのシステムテーブルから情報を得るために必 + 要な SELECT 文が沢山あります。
-カーネルが共有メモリーを持つ設定になっていなかったか、でなければ、カーネルに対して使える共有メモリーの大きさを大きく設定する必要があります。具体的な大きさは、使っているアーキテクチャとpostmaster を走らせるときに設定するバッファの数とバックエンドプロセスに依存します。ほとんどのシステムでは、既定値のバッファサイズのままで、少なくとも約1MBが必要です。 -PostgreSQL - Administrator's Guide/Server Run-time Environment/Managing Kernel Resources -に共有メモリーとセマフォについての情報の詳細がありますのでご覧ください。
+カラムのデータ型の変更は 8.0 以降では、 + ALTER TABLE ALTER COLUMN TYPE を使うことにより間単に + なりました。
-もしエラーメッセージがIpcSemaphoreCreate: semget failed (No space left on device)であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策はpostmasterを起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを-Nで使います。より恒久的な解決策は、カーネルのSEMMNS と SEMMNI パラメータを増やすことです。 -
+それより前のバージョンでは、以下のようにします:
++ BEGIN; + ALTER TABLE tab ADD COLUMN new_col new_data_type; + UPDATE tab SET new_col = CAST(old_col AS new_data_type); + ALTER TABLE tab DROP COLUMN old_col; + COMMIT; +-
操作不能のセマフォも過度なデータベースアクセスの間にクラッシュを -起こす可能性があります。 -
+これを行なったときは、抹消された行が使っているディスク空間を回収 + するためにVACUUM FULL tabをしたほうが良いかもしれません。
-もし、エラーメッセージがなにか他のものであれば、カーネルの構成でまったくセマフォのサポートをしていないかもしれません。 -PostgreSQL Administrator's Guide に共有メモリーとセマフォについての情報の詳細があります。
+制限は以下のとおりです:
++-+
++ データベースの最大サイズ? 制限無し (32 TB のデータベースも存在します) + テーブルの最大サイズ? 32 TB + ロウの最大サイズ? 1.6TB + フィールドの最大サイズ? 1 GB + テーブル内での最大ロウ数? 制限無し + テーブル内での最大カラム数? カラムの型によって 250-1600 + テーブル内での最大インデックス数? 制限無し
もちろん、これらは実際は無制限ではなく、ディスク容量とメモリーや + スワップスペースの大きさにより制限されます。性能はこれらの値がことの + ほか大きな時に煽りを受けます。
-既定値では、PostgreSQL は Unix ドメインソケット、または、TCP/IP接続のローカルマシンからの接続しか許しません。postgresql.conf の中の listen_addresses を修正し、かつ、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型認証を有効にしないかぎりは、他のマシンからは接続できないでしょう。 -
+最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファ + イルのサポートは必要としません。巨大なテーブルは複数の1GBのファイル + に分けて保存されますので、ファイルシステムの制限は重要ではありません。 +
-デフォルトのブロックサイズを32kにすることで、最大テーブルサイズ + と最大カラム数とを4倍にすることができます。
-確かにインデックスは問い合わせの速度を増します。EXPLAIN ANALYZEコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。 -
-もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中に無い文は、それら自身がそれぞれのトランザクションに入っていると見なされます。いくつかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが減ります。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。 -
-- Administration Guide/Server Run-time Environment/Run-time - Configurationには、 -チューニングのオプションがいくつかあります。fsyncオプションでfsync() を無効にすることができます。これによって、各トランザクション毎に fsync() でディスクを更新するのを止めさせます。 -
+shared_buffersオプションを使ってバックエンド・プロセスにより使われる共有メモリー・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、カーネルの共有メモリー空間の制限値を越えてしまうために postmaster が走らなくなるでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 1000 です。 -
+普通のテキストファイルを PostgreSQL のデータベースに保存するには、 + 最大で約5倍のディスク容量を必要とします。
-sort_mem (PostgreSQL 8.0からは: work_mem)オプションを使って、それぞれのバックエンド・プロセスが一時的な並べ替えによって使うメモリーの最大サイズを増やすこともできます。 既定値は 1024 (すなわち、1MB)です。 -
-また、CLUSTER コマンドを使って、テーブルのデータをインデックスに合わせるためにグループ化することもできます。詳しくは、オンラインマニュアルで CLUSTER を見て下さい。 -
+例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを + 考えてみましょう。テキストの文字列の平均長さを20バイトと仮定すると、 + フラットファイルの大きさは約2.8MB です。このデータを含む PostgreSQL + データベースファイルの大きさは次のように約6.4MBと見積もることができ + ます： -
+ 32 bytes: 各ロウのヘッダ(概算) + 24 bytes: 整数(int)フィールドとテキスト(text)フィールド + + 4 bytes: ページ上のタップルへのポインタ + ---------------------------------------- + 60 bytes per row --PostgreSQL は、デバグのために意味のある、状態情報を報告するいくつかの機能を持ちます。 -
+ PostgreSQL のデータページサイズは 8192バイト(8KB)なので: -まず、--enable-cassert オプションで configure を走らせます。そうしてコンパイルすることにより、沢山の assert() が、バックエンドの進捗状況を監視し、何か予期せぬことが起きるとプログラムを停止するようになります。 -
+ 8192 bytes per page + ------------------- = 136 rows per database page (切り捨て) + 60 bytes per row -postmaster と postgres の両方でいくつかのデバグ・オプションの利用ができます。まず、次のように postmaster を起動するときはいつでも、標準出力とエラー出力をログ・ファイルに送るようにしてあることを確かめて下さい。 -
+ 100000 data rows + -------------------- = 782 database pages (切り上げ) + 128 rows per page + + 735 database pages * 8192 bytes per page = 6,021,120 bytes (6 MB) +
- cd /usr/local/pgsql - ./bin/postmaster >server.log 2>&1 & -+
インデックスは、これほどのオーバヘッドは要求しませんが、インデッ + クス付けされるデータを含む以上、それなりに大きくなります。
+NULLはビットマップとして保存されていて、それらがわ + ずかにスペースを使います。
-これにより PostgreSQL の最上部のディレクトリに server.log ファイルが置かれます。このファイルはサーバーが遭遇した問題やエラーについて有用な情報を含みます。Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オプションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファイルを生成することに注意しなくてはなりません。 -
-もし、postmasterが走っていなければ、postgresバックエンドをコマンドラインから走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。 -
+ もし、postmasterが走っていれば、あるウィンドウでpsqlを開始すると、SELECT pg_backend_pid()を使って、psql で使われる postgres プロセスのPIDが見つかります。
-デバッガを使ってpostgresのPIDにアタッチ(attach)します。デバッガの中からブレーク・ポイントをセットし、psql から問い合わせを発行します。デバグのためにpostgresを始動する場合は、PGOPTIONS="-W n" を設定でき、それから、psql を開始します。これにより、n 秒開始を遅らせるはずなので、デバッガでプロセスにアタッチして、ブレークポイントを設定し、開始から順を追って見てゆくことができます。
-
いくつかのlog_*サーバ構成変数は、デバッグと性能測定にとても役に立つプロセスの統計の印刷を可能にします。
-
インデックスは、すべてのクエリで使われるわけではありません。テー + ブルが最小サイズより大きく、クエリでそのわずかなパーセンテージのロウ + を選択する時だけ、インデックスは使われます。これはインデックススキャ + ンにより起こされるランダムなディスクアクセスは、テーブルをストレート + に読む順次走査よりも遅くなることがあるからです。
-何という関数がどのくらい実行時間を食っているかを見るために、プロファイリング（プロフィール付き）でコンパイルすることも可能です。そのバックエンドのプロフィール・ファイルは pgsql/data/base/dbname ディレクトリに格納されるでしょう。クライアントのプロフィールはクライアントの現行ディレクトリに置かれるでしょう。Linux でまともなプロファイリングを行うには -DLINUX_PROFILE でコンパイルする必要があります。 -
+インデックスを使うかを決定するために、PostgreSQL はテーブルについ + ての統計情報を持たなければなりません。この統計情報は、 + VACUUMANALYZEまたは、単に ANALYZE を使っ + て収集することができます。統計情報を使ってオブティマイザはテーブルの + 中にあるロウ数を知り、インデックスを使うべきかの決定をより正しくでき + ます。統計情報は最適な結合順や結合方法を決める上でも貴重なものもあり + ます。統計情報の収集は、テーブルの内容がかわると毎に繰返しなされるべ + きです。
-インデックスは、通常 ORDER BY や結合を行なうため + には使われません。順次スキャンに続く明示的ソートは、巨大なテーブルの + インデックススキャンよりも普通は高速です。
-postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があります。 -
-既定の最大プロセスは32プロセスです。-Nに適切な値を引数にしてpostmasterを再起動するか、PostgreSQL.conf を修正することによって、その値を増やすことができます。 -
+ しかし、ORDER BYと組み合わされたLIMIT + は、テーブルの小さな部分を返すためにたびたびインデックスを使うでしょ + う。実際、MAX() や MIN() がインデックスを使わないとしても、このよう + な値をORDER BY と LIMIT を使ってインデックスを使って取り出すことが可 + 能です: -もし、-N を 32よりも大きくするのであれば、-Bも既定の64より大きい値に増加させなくてはならないし、-B は少なくとも -N の2倍はなくてはならず、おそらく最高性能を望むならばそれより大きい値が必要なはずです。バックエンドプロセスをたくさんにすると、いろいろなUnixカーネル構成パラメータも増やすことが必要になるかもしれません。 -共有メモリー・ブロックの最大値(SHMMAX)、 -セマフォの最大数(SEMMNSとSEMMNI)、 -プロセスの最大数(NPROC)、 -ユーザ毎の最大プロセス数(MAXUPRC)、 -開くファイルの最大数(NFILEとNINODE) -も確認事項に含まれます。 -PostgreSQLに許されるバックエンドのプロセス数が制限されているのは、 -システムのリソースを使い果してしまうことを避けるためです。 -
++ SELECT col + FROM tab + ORDER BY col [ DESC ] + LIMIT 1; +-
もし、オプティマイザが間違ってシーケンシャルスキャンを選択したこ
+ とに疑いがなければ、SET enable_seqscan TO 'off'に設定し
+ て、クエリをもう一度実行視、インデックススキャンがまちがいなく速くなっ
+ ているかどうかをみてください。
LIKE あるいは ~ のようなワイルドカード演算 + 子は特別な環境でしか使えません： +
LIKEイン + デクシングにだけ働くような、特別な
text_pattern_opsイ + ンデックスを作成することもできます。 +
+ +
8.0より前のリリースでは、インデックスは、データ型がちょうどインデッ + クスのカラムの型と一致しなければ、使えないことがしばしばありました。 + おそらく、int2, int8, および numeric 等のカラムのインデックスがそう + です。
+ + +オンラインマニュアルで EXPLAIN を見てください。
+ +~演算子は正規表現照合を行ない、~* は大文字と小文字 + を区別しない(case-insensitive)正規表現照合を行います。 大文字と小文 + 字を区別しない LIKE 演算子を ILIKE と + いいます。
+ +大文字と小文字を区別しない等値比較は次のように表現できる： +
+ SELECT * + FROM tab + WHERE lower(col) = 'abc'; +-
問い合わせ実行モジュールによって生成された一時的なファイルが、このディ -レクトリに含まれます。例えば、もし ORDER BY 句を満たすためにバックエンドの -S パラメータで許可した値よりも大きなスペースがソートの際に必要だとすると、溢れたデータを保持するために一時的なファイルがいくつかここに生成されます。 -
--一時的なファイルは自動的に消し去られるはずですが、もし、ソートの途中でバックエンドがクラッシュしてしまうとそうはなりません。postmasterの停止とリスタートでこれらのファイルはディレクトリから消しさられます。 -
+標準インデックスでは使われず、しかしながら、もし、式インデックス + を作ったならそれが使われるでしょう。
-- [訳注： - SYSLOGD 経由でログを出力するには、まず、configure を --enable-syslog - 付きで走らせた後、コンパイルとインストールを行ないます。 - 次に、syslog.conf に local?.* の 出力先を指定し(環境変数で変更可能)、 - syslogd に HUP シグナルを送って初期化しておきます。そして、 - $PGDATA/pg_options に syslog=2 を加えて、 postmaster を -S - オプション付きにてサーバモードで起動します。(バージョン 7.1 からは - pg_options は PostgreSQL.conf になっています。) - ] -+
+ CREATE INDEX tabindex ON tab (lower(col)); +-
-PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から 7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような)では、システムテーブルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出力し、それを新しい内部フォーマットに読み込むことができます。
--ディスク上でのフォーマットに変更のない同一リリースでは、アップグレードは、ダンプ／リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノートには、pg_upgrade が利用可能なリリースかどうか記されています。
--PCハードウェアはほとんど互換性がありますので、ほとんどの人は、すべてのPCハードウェアが同じ品質だと思い込む傾向があります。しかし、それは間違いです。ECC RAM、SCSI、および、高品質マザーボードは、安いハードウェアに比べると、より信頼性が高く、より性能も良いのです。PostgreSQL はほとんどのハードウェアで稼働しますが、信頼性や性能が重要な場合は、ハードウェアのオプションを研究することが賢明です。メーリングリストでもハードウェアオプションとトレードオフについて議論することができます。
+以下のように、IS NULL と IS NOT + NULLで、そのカラムをテストしてみます：
-+ SELECT * + FROM tab + WHERE col IS NULL; +-
NULL状態でソートするには、IS NULL と + IS NOT NULL の修飾子を ORDER BY 句の中 + で使ってみます。true のものは false のものよりも高い値 + として並べられますので、次の例では NULL の記載が結果リストの上部に置 + かれます。 -
詳述は、オンラインマニュアルで DECLARE を見て下さい。 -
++ SELECT * + FROM tab + ORDER BY (col IS NOT NULL) +-
オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。 -
+たとえ、欲しいのは最初の数ロウだけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを使うことを考えてみて下さい。 -もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数ロウだけで評価できるかもしれませんが、でなれば、PostgreSQL は意図したロウが生成されるまですべてのロウを評価しなければならないかもしれません。 -
++-+
++ 型 内部名 備考 + VARCHAR(n) varchar 最大長のサイズを指定する、詰め物無し + CHAR(n) bpchar 指定された固定長となるように空白が詰められる + TEXT text 長さに特別な上限は無し + BYTEA bytea 可変長のバイト配列(null-byte safe) + "char" char 1文字
ランダムなロウをSELECTするには、次の文を使います： -
-- SELECT col - FROM tab - ORDER BY random() - LIMIT 1; -+
内部名にお目にかかるのは、システム・カタログを調べるときや、エラー + メッセージを受け取るときです。
-- psqlの中で、 \dt コマンドを使ってテーブルを見ます。psql の中のコマンドの完全なリストには \? を使えます。あるいは、psqlのソースコードのpgsql/src/bin/psql/describe.cファイルを見ることもできて、その中にはpsqlのバックスラッシュコマンドの出力を生成するSQLコマンドが含まれています。また、psqlを -E オプションと一緒に開始すると、実行させたコマンドを実行するために使う問い合わせを出力するようになります。PostgreSQLはまた、SQLi対応の INFORMATION SCHEMA インターフェースを用意していて、データベースについての情報を得るために問い合わせを使うことができます。 -
+上記の型のうち最初の４つの型は "varlena" 型です(すなわち、ディス + クの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。 + このように実際の空間は宣言された大きさよりも少し大きくなります。しか + し、長い値は圧縮されるので、ディスク上の空間は思ったよりも小さくなります。
+VARCHAR(n) は可変長の文字列を保存するのに最適です + が、保存できる文字列の長さに制限があります。TEXT は長 + さに制限の無い文字列の保存のためのもので、最大で 1ギガバイトです。 + CHAR(n)は、VARCHAR(n)が与えられた文字 + だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を + 保存するのに最適です。BYTEAは、部分的に + NULL のバイトを含むバイナリデータを保存するためのもの + です。これらのタイプは同じくらいの性能特性をもちます。
-DROP COLUMN機能が、ALTER TABLE DROP COLUMN としてリリース7.3 -に加えられました。それまでのバージョンでは、その代わりにこうします: -
+- 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; -+
PostgreSQL は SERIAL データ型をサポートします。カ + ラム上にシーケンスを自動作成します。たとえば、
-カラムのデータタイプは次の文で変えられます： -
++ CREATE TABLE person ( + id SERIAL, + name TEXT + ); ++ は自動的に次のように翻訳されます: +
+ CREATE SEQUENCE person_id_seq;
+ CREATE TABLE person (
+ id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
+ name TEXT
+ );
+ [訳注：
+ CREATE UNIQUE INDEX person_id_key ON person ( id );
+ は、 7.3 以降は自動的には行なわれなくなりました。
+ ]
+
+ 通番についてのもっと詳しい情報は、オンラインマニュアルで
+ create_sequence をごらんください。
-- BEGIN; - ALTER TABLE tab ADD COLUMN new_col new_data_type; - UPDATE tab SET new_col = CAST(old_col AS new_data_type); - ALTER TABLE tab DROP COLUMN old_col; - COMMIT; --
これを行なったときは、抹消された行が使っているディスク空間を回収するためにVACUUM FULL tabをしたほうが良いかもしれません。 -
+ひとつの方法は、nextval() 関数を使ってその値を挿入する + 前(before)に SEQUENCE オブジェクトから次の SERIAL + 値を取り出し、それから実際に挿入をすることです。4.11.1 のテーブルの例を使うとすると、疑似言語では + このようになります。
-制限は以下のとおりです。 -
--データベースの最大サイズ? 制限無し (32 TB のデータベースも存在します) -テーブルの最大サイズ? 32TB -ロウの最大サイズ? 1.6TB -フィールドの最大サイズ? 1GB -テーブル内での最大ロウ数? 制限無し -テーブル内での最大カラム数? カラムの型により250-1600 -テーブル内での最大インデックス数? 制限無し -+
+ new_id = execute("SELECT nextval('person_id_seq')");
+ execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
+
-もちろん、これらは実際は無制限ではなく、ディスク容量とメモリーやスワップスペースの大きさにより制限されます。性能はこれらの値がことのほか大きな時に煽りを受けます。 -
+ そうして、new_id に保存した新しい値を他のクエリ(たとえば、 + person テーブルに対する外部キー(foreign key)のように)使うと + よいでしょう。自動的に作られたSEQUENCEオブジェクトの + 名前は、<table>_<serialcolumn>_seq + のようになり、このうち、table と serialcolumn はそれぞ + れテーブルの名前とSERIALカラムの名前です。 -最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファイルのサポートは必要としません。巨大なテーブルは複数の1GBのファイルに分けて保存されますので、ファイルシステムの制限は重要ではありません。 -
+あるいは、与えられたSERIAL値を、それが既定値として + 挿入された後で(after)、 currval() 関数を使って取り出す + こともできます。たとえば、
-デフォルトのブロックサイズを32kにすることで、最大テーブルサイズと最大カラム数とを４倍にすることができます。 -
+
+ execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
+ new_id = execute("SELECT currval('person_id_seq')");
+
--普通のテキストファイルを PostgreSQL のデータベースに保存するには、最大で約5倍のディスク容量を必要とします。
+例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを考え -てみましょう。テキストの文字列の平均長さを20バイトと仮定すると、フラット -ファイルの大きさは約2.8MB です。このデータを含む PostgreSQL データベース -ファイルの大きさは次のように約6.4MBと見積もることができます： -
+それはありません。currval() は、すべてのユーザではありませ + んが、読者のセッションに与えられた現在の値を返します。
-- 32 bytes: 各ロウのヘッダ(概算) - 24 bytes: 整数(int)フィールドとテキスト(text)フィールド - + 4 bytes: ページ上のタップルへのポインタ - ---------------------------------------- - 60 bytes per row - PostgreSQL のデータページサイズは 8192バイト(8KB)なので: +- -4.11.4) トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜですか？シーケンス／SERIALカラムに空きがあるのはなぜですか？
- 8192 bytes per page - ------------------- = 136 rows per database page (切り捨て) - 60 bytes per row +同時性を改善するために、実行中のトランザクションに、必要に応じてト + ランザクションが終了するまでロックされないようシーケンス値を与えてい + ます。このためトランザクションが中断されると番号割り当てにギャップを + 生じます。
- 100000 data rows - -------------------- = 782 database pages (切り上げ) - 128 rows per page - - 735 database pages * 8192 bytes per page = 6,021,120 bytes (6 MB) -
-インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。 -
-NULLはビットマップとして保存されていて、それらがわずかにスペースを使います。 -
- -psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。また、pg_ で始まるシステムテーブルにも記述されています。さらに、psql -l はすべてのデータベースをリスト表示します。 -
- -また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。 -
- --インデックスは自動的にすべての問い合わせで使われるわけではありません。テー -ブルが最小サイズより大きく、問い合わせでそのわずかなパーセンテージのロウを -選択する時だけ、インデックスは使われます。これはインデックススキャンによ -り起こされるランダムなディスクアクセスは、テーブルをストレートに読む順次 -走査よりも遅くなることがあるからです。 -
- -インデックスを使うかを決定するために、PostgreSQL はテーブルについ -ての統計情報を持たなければなりません。この統計情報は、VACUUM -ANALYZEまたは、単に ANALYZE を使って収集すること -ができます。統計情報を使ってオブティマイザはテーブルの中にあるロウ数を知 -り、インデックスを使うべきかの決定をより正しくできます。統計情報は最適 -な結合順や結合方法を決める上でも貴重なものもあります。統計情報の収集は、 -テーブルの内容がかわると毎に繰返しなされるべきです。
- -インデックスは、通常 ORDER BY や結合を行な -うためには使われません。順次スキャンに続く明示的ソートは、巨大なテーブル -のインデックススキャンよりも普通は高速です。
-- しかし、ORDER BYと組み合わされたLIMIT -は、テーブルの小さな部分を返すためにたびたびインデックスを使うでしょう。 -実際、MAX() や MIN() がインデックスを使わないとしても、このような値を -ORDER BY と LIMIT を使ってインデックスを使って取り出すことが可能です: -
- -- SELECT col - FROM tab - ORDER BY col [ DESC ] - LIMIT 1; -- -
もし、オプティマイザが間違ってシーケンシャルスキャンを選択したことに疑いがなければ、SET enable_seqscan TO 'off'を使ってインデックススキャンでまちがいなく速くなっているかをテストをしてみてください。
LIKE あるいは ~ のようなワイルドカード演算 -子は特別な環境でしか使えません： -
-LIKEインデクシングにだけ
-働くような、特別なtext_pattern_opsインデックスを作成
-することもできます。
-8.0より前のリリースでは、インデックスは、データ型がちょうどインデックスのカラムの型と一致しなければ、使えないことがしばしばありました。おそらく、int2, int8, および numeric 等のカラムのインデックスがそうです。
-[訳注： - 強制的にインデックスを使うには SET enable_seqscan = off を実行します。 -] +PostgreSQLでつくられるすべてのロウは、WITHOUT OIDS + でつくられないかぎり一意のOIDを得ます。 + OIDは自動的に4バイトの整数で与えられ、それは、全イン + ストレーションを通して一意な値となります。しかし、約40億でオーバーフ + ローし、そして、OIDは重複をしはじめます。PostgreSQLは + 内部システムテーブルを一緒にリンクするtためにOID を使 + います。 -
ユーザのテーブルのカラムに一意の番号を付けるためには、 + OID ではなく SERIAL を使うのが最もよい + でしょう。SERIALの連番は1つのテーブル内でのみ一意にな + るからで、オーバーフローを起こしにくいと考えられます。 + 8バイトのシーケンス値を保存するために、SERIAL8があり + ます。
-オンラインマニュアルで EXPLAIN を見て下さい。 -
+CTID は、特定の物理ロウをブロックとオフセットの値 + で識別するために使われます。CTIDは、ロウが修正された + り再読込みされたときに変わります。また、物理ロウを差すためにインデッ + クスの記載に使われます。
-R-tree インデックスは空間的なデータにインデックスを付けるために使われます。ハッシュインデックスでは範囲の検索ができません。また、B-tree インデックスでは、１次元でしか範囲の検索ができません。R-tree インデックスであれば多次元のデータを扱えます。たとえば、もし R-tree インデックスを point 型の属性に付けることができるとするとシステムは、「長方形に囲まれた点をすべて選択する」というような問い合わせに、より効率良く答えられます。 -
+R-Tree の設計の原典となる権威ある論文は: -
+おそらく、システムの仮想メモリーを全て使い果たしてしまっている可 + 能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能 + 性があります。postmaster を始動する前にこれを試してみてください：
-Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." -Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57. -
++ ulimit -d 262144 + limit datasize 256m +-
この論文は、Stonebraker 教授の "Readings in Database Systems" -でも取り上げられています。 -
+ シェルによって、どちらかひとつが成功するでしょうが、これはプロセスの + データセグメント制限をより高く設定し、たぶんクエリが完結するようにな + るでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後 + に作られる全てのサブプロセスについて適用されます。バックエンドがとて + も多くのデータを返すためにSQL クライアントで問題が続 + いているのであれば、クライアントを開始する前にこれを試してみてくださ + い。 -- [訳注： - 奈良先端大の石川佳治さんよりR-Tree関係の文献を紹介して頂きました。 - 日本語 Postgres ML のアーカイブから "Subject: [postgres95 801] spatial data structures" - http://www.sra.co.jp/people/t-ishii/PostgreSQL/mhonarc/pgsql-jp/1996Oct/msg00007.html - をご覧下さい。 - ] -+
組込みの R-Tree でポリゴンやボックスを操作できます。理論的にはR-Tree はもっと高い次元を操作するようにも拡張できます。実質的には、R-Tree の拡張にはちょっとした作業が必要でして、現在、我々はそれをどのようにするかについての文書を持っていません。 -
+psql から SELECT version(); をタイプします。
- [訳注： - R-Tree インデックスはGiSTで開発されています。 - http://www.sai.msu.su/~megera/postgres/gist/ - ] -+
CURRENT_TIMESTAMPを使います:
++ CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); +-
GEQO モジュールは、沢山のテーブルを結合するときに、遺伝的アルゴリズム(GA)で問合わせを高速化します。これにより、しらみつぶしに探索を行なわなくても、大きな結合(join queries)を扱うことができるようになります。 -
--~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。 大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。 -
+PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポー + トします。ここに 2つの例題があります。
-大文字と小文字を区別しない等値比較は次のように表現できる： -
- -+SELECT * - FROM tab - WHERE lower(col) = 'abc'; ---標準インデックスでは使われず、しかしながら、もし関数インデックスを -作ったならそれが使われるでしょう。 -
-- CREATE INDEX tabindex ON tab (lower(col)); -- - -4.13) 問い合わせの中で、フィールドが NULL であることを検出するにはどうしますか？ -
- -カラムを IS NULL と IS NOT NULL -とで試してみます。
- -4.14) 様々な文字型のそれぞれの違いは何ですか？ -
- --Type Internal Name Notes --------------------------------------------------- -VARCHAR(n) varchar 最大長のサイズを指定する、詰め物無し -CHAR(n) bpchar 指定された固定長となるように空白が詰められる -TEXT text 長さに上限の無いテキスト -BYTEA bytea 可変長のバイト配列(null-byte safe) -"char" char １文字 -- -内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。 -
- -上記の型のうち最初の４つの型は "varlena" 型です(すなわち、ディスクの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数ロウに渡って保存されたりして、ディスク上の空間は思ったより小さくなります。 -
- -VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存のためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性をもちます。
- -4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？ -
- -PostgreSQL は SERIAL データ型をサポートします。カラム上にシーケンスを自動作成します。たとえば、 -
- -- CREATE TABLE person ( - id SERIAL, - name TEXT - ); ---は自動的に次のように翻訳されます: -
-- CREATE SEQUENCE person_id_seq; - CREATE TABLE person ( - id INT4 NOT NULL DEFAULT nextval('person_id_seq'), - name TEXT - ); - - [訳注： - CREATE UNIQUE INDEX person_id_key ON person ( id ); - は、 7.3 からは自動的には行なわれなくなりました。 - ] ---通番についてのもっと詳しい情報は、オンラインマニュアルで create_sequence をご覧下さい。 -
-また、各ロウのOIDフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてリロードする必要がある場合は、OIDを温存するためにpg_dump で -oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があります。 -
- -4.15.2) SERIALデータ型に挿入される値は、どうすれば得られますか？ -
-ひとつの方法は、nextval() 関数を使ってその値を挿入する前(before)に SEQUENCE オブジェクトから次の SERIAL 値を取り出し、それから実際に挿入をすることです。4.15.1 のテーブルの例を使うとすると、疑似言語ではこのようになります。 -
- -- new_id = execute("SELECT nextval('person_id_seq')"); - execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')"); -- --そうして、new_id に保存した新しい値を他の問い合わせに(たとえば、person テーブルに対する外部キー(foreign key)のように)使うとよいでしょう。自動的に作られたSEQUENCEオブジェクトの名前は、<table>_<serialcolumn>_seq のようになり、このうち、table と serialcolumn はそれぞれテーブルの名前とSERIALカラムの名前です。 -
--あるいは、与えられたSERIAL値を、それが既定値として挿入された後で(after)、 currval() 関数を使って取り出すこともできます。たとえば、 -
- -- execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); - new_id = execute("SELECT currval('person_id_seq')"); -- --最後に、INSERT文から返るOIDを使って、既定値をみつけることもできますが、しかし、oidの値は40億に達するともとに戻ってしまい、最も移植性の低いやり方となるでしょう。Perl DBI の DBD::Pg モジュールを使えば、$sth->execute() の後に $sth->{pg_oid_status} を経由してその OID 値を使えるようにすることはできます。 -
- -4.15.3) currval() は他のユーザとの競合状態に陥ることはないですか？ -
- -それはありません。currval() は、すべてのユーザではありませんが、あなたのバックエンドに与えられた現在の値を返します。 -
- -4.15.4) トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜですか？シーケンス／SERIALカラムに空きがあるのはなぜですか？ -
- -同時性を改善するために、実行中のトランザクションに、必要でトランザクションが終了するまでロックされないシーケンス値を与えています。このためトランザクションが中断されると番号割り当てにギャップを生じます。 -
- -4.16) OID とは何ですか？ TID とは何ですか？ -
- -OID とは一意のロウID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべてのロウは一意の OID を得ます。initdb で発生される OID はすべて 16384 (include/access/transam.h から)より小さな値です。initdb 後のすべての OID (ユーザ作成)はそれ以上の値になります。 -既定では、これらすべての OIDは一つのデーブルやデータベース内に留まらず、PostgreSQL インストレーション全体の中で一意です。 -
- -PostgreSQL はテーブル間のロウを結びつけるために、そのシステムテーブル内に OID を使います。この OID は特定のユーザのロウを識別するためや結合の中で使われることができます。OID の値を保存するためには OID 型をカラムに使うことを奨めます。より速くアクセスするために OID フィールドにインデックスを作ることができます。 - - OID は、全てのデータベースで使われる中央領域から、全ての新しいロウに割り当てられます。OID を他の何かに変えたい、あるいは元の OID もテーブルと一緒にコピーしたいのなら、できなくはありません。 - -
- -- CREATE TABLE new_table(mycol int); - SELECT oid AS old_oid, mycol INTO tmp_table FROM old_table; - COPY tmp_table TO '/tmp/pgtable'; - COPY new_table WITH OIDS FROM '/tmp/pgtable'; - DROP TABLE tmp_table; -- -OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。 -
- -TID は特定の物理ロウをそのブロックとオフセット値で識別するために使われます。TID はロウが修正されたり再ロードされると変わります。それらの TID は、物理ロウを指すためにインデックス記載で使われます。 -
- -4.17) PostgreSQL で使われるいくつかの用語の意味は何ですか？ -
- -いくつかのソースコードや古い文書の中には、それぞの専門分野の中でもっと一般的に使われる専門用語が使われています。 -
- -
一般的なデータベース用語のリストは：http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html -で見つけられます。
- --おそらく、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。 -postmaster を始動する前にこれを試してみて下さい： -
- -- ulimit -d 262144 - limit datasize 256m -- -
-シェルによって、どちらかひとつが成功するでしょうが、これはプロセスのデータセグメント制限をより高く設定し、たぶん問い合わせが完結するようになるでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスについて適用されます。バックエンドがとても多くのデータを返すためにSQL クライアントで問題が続いているのであれば、クライアントを開始する前にこれを試してみてください。 -
- -
-psql から SELECT version(); をタイプします。
-
ラージ・オブジェクト操作をするときは、前後にBEGIN WORKとCOMMITを付ける必要があります。すなわち、lo_open ... lo_closeをはさみ込みます。 -
- -現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、lo_openコマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、invalid large obj descriptor(ラージ・オブジェクトの記述子が不正)となります。それで、もし、トランザクションを使うのを忘れると、（少なくともほとんどの時間）働いていたコードがエラーメッセージを出すのです。 -
- -もし、ODBCのようなクライアントインターフェイスをお使いなら、auto-commit offを設定する必要があるかもしれません。 -
- - -CURRENT_TIMESTAMPを使います: -
-- CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP ); -- -
- 7.4 より前のバージョンでは、副問い合わせは、副問い合わせの結果を外部問い合わせの各ロウについて順次走査することによって、外部の問い合わせに結合させられる。
-副問い合わせがわずかなロウしか返さず、外部問い合わせが沢山のロウを返す場合は、INが最も早いです。他の問い合わせを高速化するには、INをEXISTSに置換します:
-
- SELECT * - FROM tab - WHERE col IN (SELECT subcol FROM subtab) --
-を、置き換えて： -
-- SELECT * - FROM tab - WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col) --
-とします。
-これが手っ取り早いですが、subcolは索引付きカラムであるべきです。
-
バージョン7.4以降では、INは、通常の問い合わせと同様の洗練されたジョインの技術を実際に使い、EXISTSを使うことを好みます。
-
-PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポートします。ここに 2つの例題があります。 -
- -- SELECT * - FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col); --
+ FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col); + あるいは -
-- SELECT * - FROM t1 LEFT OUTER JOIN t2 USING (col); --
-これらの象徴的な問い合わせでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。通常、結合はINNER結合と呼ばれます。 -
--以前のリリースでは外部結合(outer join)をUNION と NOT IN を使ってシミュレートできます。 -たとえば、tab1 と tab2 を結合するときは、次の問い合わせで二つのテーブルを外部結合します。 -
-- SELECT tab1.col1, tab2.col2 - FROM tab1, tab2 - WHERE tab1.col1 = tab2.col1 - UNION ALL - SELECT tab1.col1, NULL - FROM tab1 - WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2) - ORDER BY col1 -- -
-現行のデータベース以外への問い合わせ方法はありません。というのもPostgreSQLがデータベース仕様のシステムカタログを読み込むためで、そこには、たとえそのふりをするだけにしろ、データベースを越えて問い合わせをするすべがありません。 -
-contrib/dblink はデータベース間(cross-database)の問い合わせを関数呼出しにより許します。もちろん、クライアントは同時に接続を別のデータベースへも張らなくてはならず、結果をクライアント側でマージしなくてはなりません。
- - -7.3では関数から、複数のロウや複数カラムを簡単に返せます。 -http://techdocs.postgresql.org/guides/SetReturningFunctions。 -
- --PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されますが、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一時テーブルアクセスのために使うことです。これで、毎回問い合わせをパースし直すことになるでしょう。
- - --[訳注 - レプリケーション関連の項目がなくなりましたが、訳注のみ残してあります。 + SELECT * + FROM t1 LEFT OUTER JOIN t2 USING (col); +- Jan Wieckさんによるカスケード可能なマスター・スレーブ型のレプリケーション Slony-I - http://gborg.postgresql.org/project/slony1/projdisplay.php +これらの象徴的なクエリでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。通常、結合はINNER結合と呼ばれます。 - 石井達夫さんによるコネクションプール サーバ PGPool - http://www2b.biglobe.ne.jp/~caco/pgpool/ - 三谷篤さんによるマルチマスタ方式の同期レプリケーション PGCluster - http://www.csra.co.jp/~mitani/jpug/pgcluster/index.html +
現行のデータベース以外への問い合わせの方法はありません。というの + もPostgreSQLがデータベース仕様のシステムカタログを読み込むためで、そ + こには、たとえそのふりをするだけにしろ、データベースを越えて問い合わ + せをするすべがありません。
+contrib/dblink はデータベース間(cross-database)の問い合わ + せを関数呼出しにより許します。もちろん、クライアントは同時に接続を別 + のデータベースへも張らなくてはならず、結果をクライアント側でマージし + なくてはなりません。
-問題は色々と考えられますが、まず最初に、作成したユーザ定義関数を単独のテストプログラムにして試してみて下さい。 -
+集合を返す関数(Set Returning Functions): + + http://techdocs.postgresql.org/guides/SetReturningFunctions + を使うと簡単です
。 -皆さんの行なった拡張を、pgsql-hackers メーリング・リストに送ってください。そして、ゆくゆくはそうした拡張が contrib/ サブディレクトリの中に入ることになるでしょう。 -
+PL/PgSQL は関数スクリプトをキャッシュし、不幸にもその副作用で、 + PL/PgSQL関数が一時テーブルにアクセスする場合、後でそのテーブルを消し + て作りなおされ、関数がもう一度呼び出されると、その関数はキャッシュし + ている関数の内容はまだ古い一時テーブルを差し示したままだからです。 + この、解決策として、PL/PgSQLの中で EXECUTE を一時テー + ブルへのアクセスのために使います。そうすると、クエリは毎回パースをや + り直しされるようになります。
-バージョン7.3以降のPostgreSQLでは、テーブルを返す関数を C, PL/PgSQL、そして SQL にて完全にサポートします。詳しくはプログラマガイドの情報を見てください。Cで定義された表を返す関数の例題がcontrib/tablefuncの中にあります。 -
+「レプリケーション」と一言で言いますすが、レプリケーションをする + ための技術はいくつかあり、それぞれ、利点と欠点があります。
-マスタ／スレーブのレプリケーションは、読み／書きのクエリを受け取 + るシングルマスタが可能で、スレーブでは 読み／SELECTの + 問い合わせだけを受け付けることができます。最も人気がある、フリーで利 + 用できる、マスタ−スレーブのPosrgreSQLレプリケーションソリューション + は、 + Slony-I です。
-いくつかの Makefile がインクルード・ファイルに対して適切な依存関係を持っていません。make clean をしてからもう一度 make を行なわなくてはなりません。もし、GCC をお使いであれば configure の --enable-depend オプションを使って、コンパイラに依存関係を自動的に調べさせることもできます。 -
+マルチ−マスタのレプリケーションは、読み／書きのクエリを受けと + り、複数のレプリケートさせるコンピュータに送ることができます。この機 + 能は、サーバ間の変更の同期が必要なため、性能に重大な衝撃を与えます。 + Pgcluster は、 + このようなソリューションとしてPosrgreSQLのためにフリーで利用できるも + のとして、最も人気があります。
-++ + +この他にも、商用やハードウェア−ベースのレプリケーションソリュー + ションがいろいろなレプリケーションモデルをサポートしています。
+ +
+[訳注： 日本語版の製作については以下の通りです。 - 最終更新日: 2005年01月12日 - 翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>) + 最終更新日: 2005年05月18日 + 翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): - 田仲 稔(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>) - 稲葉 香理(Kaori Inaba <i-kaori at sra.co.jp>) - 石井 達夫(Tatsuo Ishii <t-ishii at sra.co.jp>) - - をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、 -和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、FreeBSD ドキュメンテーションプロジェクト、 -その他、直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの皆さんに感謝します。 - - 日本語版のこの文書は、以下からもたどれます。 - http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問) - http://www.PostgreSQL.jp/wg/jpugdoc/JPUG文書・書籍関連分科会 - http://www.linux.or.jp/JF/Linux JFプロジェクト - - なお、この和訳に関するご意見は(juk at PostgreSQL.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>) + 稲葉 香理(Kaori Inaba <i-kaori at sra.co.jp>) + 石井 達夫(Tatsuo Ishii <t-ishii at sra.co.jp>) + + をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリ + スト、 和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェ + クト、FreeBSD ドキュメンテーションプロジェクト、 その他、直接あるい + は間接的にかかわっているすべてのオープンソースコミュニティーの皆さんに + 感謝します。 + + 日本語版のこの文書は 本家 "Frequently Asked Questions" のページに "Japanese FAQ" という見出であります。 + また、最新版は以下のサイトにあります。 + http://www.PostgreSQL.jp/wg/jpugdoc/JPUG文書・書籍関連分科会 + http://www.linux.or.jp/JF/Linux JFプロジェクト + http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問) + + なお、この和訳に関するご意見・ご質問は(juk at PostgreSQL.jp)までお寄せください。 ] -+