PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ) 原文最終更新日: 20:33, 25 December 2009 Contents ・ 1 一般的な質問 □ 1.1 1.1) PostgreSQLとは何ですか？その呼び方は？ Postgresとは？ □ 1.2 1.2) 誰が PostgreSQL をコントロールしていますか？ □ 1.3 1.3) PostgreSQL のラインセンスはどうなってますか？ □ 1.4 1.4) PostgreSQLをサポートするプラットホームは？ □ 1.5 1.5) PostgreSQL はどこから入手できますか？ □ 1.6 1.6) 最新のリリースはどれですか？ □ 1.7 1.7) サポートはどこで受けられますか？ □ 1.8 1.8) バグレポートはどのように発信しますか？ □ 1.9 1.9) 既知のバグや未だ無い機能はどうやって見つけますか？ □ 1.10 1.10) どのような文書がありますか？ □ 1.11 1.11) SQL はどうすれば学べますか？ □ 1.12 1.12) パッチを提供したり、開発チーム参加するにはどうすればよいです か？ □ 1.13 1.13) 他のDBMSと比べPostgreSQLはどうなのですか？ ☆ 1.13.1 機能(Features) ☆ 1.13.2 性能(Performance) ☆ 1.13.3 信頼性(Reliability) ☆ 1.13.4 サポート(Support) ☆ 1.13.5 価格(Price) □ 1.14 1.14) PostgreSQLを組み込みに使えますか？ □ 1.15 1.15) PostgreSQLのメーリングリストの購読をやめるにはどうすればよい ですか？また、電子メールを重複して受け取らないようにするにはどうします か？ ・ 2 ユーザ・クライアントの質問 □ 2.1 2.1) PostgreSQL にはどんなインターフェースが使えますか？ □ 2.2 2.2) PostgreSQL を Web ページと連携させるにはどんなツールがあります か？ □ 2.3 2.3) PostgreSQL にグラフィカル・ユーザインターフェースはありますか ？ ・ 3 管理上の質問 □ 3.1 3.1) どのようにすれば /usr/local/pgsql 以外の場所にインストールでき ますか？ □ 3.2 3.2) 他のホストからの接続はどのように制御しますか？ □ 3.3 3.3) より良い性能を得るためには、データベース・エンジンをどのように 調整しますか ☆ 3.3.1 クエリの変更 ☆ 3.3.2 サーバ構成 ☆ 3.3.3 ハードウェアの選定 □ 3.4 3.4) どのようなデバグ機能が使えますか？ □ 3.5 3.5) 接続しようとするときに 'Sorry, too many clients' が出るのはな ぜですか？ □ 3.6 3.6) PostgreSQLのアップグレードの手順はどうなりますか？ □ 3.7 3.7) PostgreSQLは国毎に最新の夏時間の変更を扱いますか？ □ 3.8 3.8) ハードウェアにはどのようなコンピュータを使えばよいですか？ ・ 4 操作上の質問 □ 4.1 4.1) 最初の数ロウのみを SELECTするにはどうしますか？ランダムなロウ ？ □ 4.2 4.2) 定義されたテーブル、インデックス、データベース、および、ユーザ をどのようにして見つけ出しますか？psqlで使われているクエリを表示するに はどうしますか？ □ 4.3 4.3) カラムのデータ型を変更するにはどうしますか？ □ 4.4 4.4) ロウ、テーブル、データベースの最大サイズは？ □ 4.5 4.5) 一般的なテキストファイルのデータを保存するには、データベースの ディスク容量はどのくらい必要です？ □ 4.6 4.6) クエリが遅いのはなぜでしょう？なぜ、インデックスが使われないの でしょうか？ □ 4.7 4.7) 問い合わせオプティマイザがどのように問い合わせを評価するのかを 見るにはどうしますか？ □ 4.8 4.8) テキスト形式の並び替え順を変更するにはどうしますか？ □ 4.9 4.9) 正規表現での検索や大文字と小文字とを区別しない正規表現検索はど のように実現しますか？大文字と小文字とを区別しない検索のためのインデッ クスはどのように使いますか？ □ 4.10 4.10) クエリの中で、フィールドがNULL であることを検出するにはどう しますか？ NULLであることを検出するにはどうしますか？フィールドがNULLか どうかでどのようにソートができますか？ □ 4.11 4.11) いろいろな文字型のそれぞれの違いは何ですか？ □ 4.12 4.12) 通番(serial)／自動増分フィールドはどのようにつくりますか？ □ 4.13 4.13) SERIALデータ型に挿入される値は、どうすれば得られますか？ □ 4.14 4.14) currval() によって他のユーザと競合状態に陥ることはないですか ？ □ 4.15 4.15) シーケンス／SERIALカラムへの割り当て番号にギャップがあるのは なぜですか？トランザクションが中断したときにもういちどシーケンス番号が 使われないのはなぜですか？ □ 4.16 4.16) OID とは何ですか？ □ 4.17 4.17) CTID とは何ですか？ □ 4.18 4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc() "が出るのはなぜですか？ □ 4.19 4.19) どのバージョンの PostgreSQL を走らせているかを調べるにはどう しますか？ □ 4.20 4.20 データベース操作の監査証跡を残す方法はありますか? □ 4.21 4.21) 現在の時刻がデフォルトとなるようなカラムはどのようにつくりま すか？ □ 4.22 4.22) 外部結合(outer join)はどのように実現しますか? □ 4.23 4.23) 複数のデータベースを使う問い合わせはどのようにすればできます か？ □ 4.24 4.24) 関数から複数のロウまたはカラムを返すにはどうしますか？ □ 4.25 4.25) PL/PgSQL の関数の中で一時テーブルにアクセスするとき、どうし て "relation with OID ##### does not exist" というエラーを受け取るので しょうか？ □ 4.26 4.26) どのようなレプリケーションのソリューションがありますか？ □ 4.27 4.27)テーブルとカラムの名前がクエリーの中で認識されないのはなぜで すか？なぜキャピタライズ(単語先頭の大文字化)は保持されないのですか? □ 4.28 4.28)データベースのパスワードを忘れてしまいました。取り戻すにはど うしますか？ □ 4.29 4.29)PostgreSQLにストアードプロシージャはありますか？ ・ 5 日本語に関する質問 □ 5.1 5.1)日本語がうまく扱えないのはなぜですか？ □ 5.2 5.2) psql でWindowsからアクセスしたときに、日本語が文字化けするので すが？ □ 5.3 5.3) PostgreSQLで日本語の全文検索はできますか？ □ 5.4 「日本語版について」 一般的な質問 1.1) PostgreSQLとは何ですか？その呼び方は？ Postgresとは？ PostgreSQLはPost-Gres-Q-L(ポスト・グレス・キュー・エル) と発音しますが、会話の 中では単純にPostgres（ポストグレス）と呼ばれることもあります。（"PostgreSQL"を どう発音するかが気になる人のために、音声ファイルを用意してあります。 PostgreSQL は、オブジェクト-リレーショナルデータベースシステムで、伝統的な商用 データベースシステムに、次世代DBMSシステムに見られるような改良が施された特徴を 有します。PostgreSQLは、自由に完全な形でそのソースコードを手に入れることができ ます。 PostgreSQL の開発は、ほとんどが、世界中にひろがったボランティアの開発者によって 、インターネットを通したコミュニケーションによって行われています。コミュニティ によるプロジェクトであるため、どの企業の制御もうけません。開発に参加したければ 、開発者向けのFAQ を見てください。 Postgresは、広く使われているPostgreSQLの愛称です。また、この名前は、バークレー でのプロジェクトで元々使われていた名前で、ほかのいずれの愛称に比べても遥かに好 ましいものです。'PostgreSQL' の発音が難しいと思われるなら、そのかわりに 'Postgres' と呼ぶようにしましょう。 1.2) 誰が PostgreSQL をコントロールしていますか？ PostgreSQLの門番、中央委員会、あるいは、コントロールをする会社を探そうとしても 、諦めざるをえず ---- 存在しないのです。我々は、中心となるコミッティとCVSコミッ タを持ちますが、これらのグループはコントロールするためというよりも、管理上のも のです。ここでは、プロジェクトは、だれでも参加ができる開発者とユーザのコミュニ ティにより方向付けられます。読者がやらなければならないことは、メーリングリスト をサブスクライブして、議論に参加することです。（開発者向けのFAQには、PostgreSQL の開発への加わり方についての情報があります。） 1.3) PostgreSQL のラインセンスはどうなってますか？ PostgreSQL は下記のラインセンスに従います。 PostgreSQLはBSDやMITに似たライセンスの下で配布されています。それは基本的には、 利用者がそのコードを好き勝手に利用することが許されています。制限があるとすれば 、このソフトウェアに伴ういかなる問題においても法的に責任を我々に負わせることが できないということです。また、この著作権表示がこのソフトウェアのすべての複製に 表示することも必要です。以下に、我々が使っているライセンス（使用許諾書）を示し ます： [訳注： 正文は英語です。参考として、訳文を併記掲載します。 ] PostgreSQL Data Base Management System Portions Copyright (c) 1996-2009, 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-2009, PostgreSQL国際開発グループ 部分的著作権 (c) 1994-1996 カリフォルニア大学本校 本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章 およびこれに続く二つの段落が全ての複製に添付されている限りにおい て、使用、複製、修正および配付の許可を、いかなる目的であっても、 無償でかつ同意書無しに行なえることをここに認めます。 カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を 含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた 損害について、たとえカリフォルニア大学がこれらの損害について訴追 を受けていたとしても、一切の責任を負いません。 カリフォルニア大学は、商用目的における暗黙の保証と、特定目的で の適合性に関してはもとより、これらに限らず、いかなる保証も放棄す ることを明言します。以下に用意されたソフトウェアは「そのまま」を 基本原理とし、カリフォルニア大学はそれを維持、支援、更新、改良あ るいは修正する義務を負いません。 [訳注： 著作権に関する正文は上記の英語による表記です。日本語訳はあくまで 参考程度としてください。 ] 1.4) PostgreSQLをサポートするプラットホームは？ 一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働させられるはずで す。最近、実際にテストを行なったことの報告がなされたプラットホームについては、 ビルドファームで見ることができます。サポート・プラットホームについてさらに詳し いことは、http://www.postgresql.org/docs/current/static/ supported-platforms.html の文書にあります。 PostgreSQL は、Win2000 SP4, WinXP, そして、Win2003 など Microsoft Windows NTベ ースのオペレーティングシステムで、ネイティブに走ります。あらかじめパッケージに されたインストーラが http://www.postgresql.org/download/windows からダウンロー ドできます。 MSDOSベースのWindowsのバージョン(Win95, Win98, WinMe)では、Cygwin を使って PostgreSQL を走らせることができます。 [訳注 日本語での情報は、次の Windows版に関するFAQの和訳をごらんください。 Running & Installing PostgreSQL On Native Windows/ja ] 1.5) PostgreSQL はどこから入手できますか？ いくつかのオペレーティングシステムとプラットホーム向けにバイナリ配布があります ； our download area をご覧ください。ソースコードは、Webブラウザ経由または、 ftp経由で取得できます。 1.6) 最新のリリースはどれですか？ PostgreSQL の最新リリース版は、我々のWebサイトで見ることができます。。我々は、1 年毎にメジャーリリースを、数ヵ月ごとのマイナーリリースを行なうことを原則として います。通常、マイナーリリースは、すべてのメジャーリリースのブランチについて同 時に行われます。メジャーリリースとマイナーリリースについて詳しくは、http:// www.postgresql.org/support/versioning をご覧ください。 [訳注 バージョン番号の x.y.z の最初の x.y がメジャーリリースの番号に相 当し、最後の z がマイナーリリースの番号になります。メジャーリリー スの番号が同じであれば、データベース・クラスタに互換性があります。 ] 1.7) サポートはどこで受けられますか？ PostgreSQL コミュニティは多くのユーザのために、電子メール経由の支援を提供してい ます。電子メールリストをサブスクライブするためのメインとなるウェブサイトは http://www.postgresql.org/community/lists/ です。これから、始めるのであれば general または、bugs といったリストがよいでしょう。 メジャーなIRC チャンネルは、Freenode (irc.freenode.net)の #postgresql というチ ャンネルです。同じネットワークに、スペイン語のチャンネル (#postgresql-es)、フラ ンス語のチャンネル(#postgresqlfr)、ブラジル語チャンネル (#postgresql-br) もあり ます。また、EFNetにもPostgreSQLチャンネルがあります。 [訳注: 1999年7月23日、日本ポストグレスユーザー会、略称JPUGが設立されました。 JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。 (2006年 特定非営利活動(NPO)法人日本PostgreSQLユーザ会になりました。 Web会員と正会員の会費は無料ですが、協賛会員の会費と会員の貢献で 会は運営されています。) 詳しくは、JPUG のWeb サイト: http://www.postgresql.jp/ をごらんください。 日本語のIRCチャンネル '#PostgreSQL:*.jp' も存在します。 ] 商用でサポートを行う会社のリストは、 http://www.postgresql.org/support/ professional_support にあります。 1.8) バグレポートはどのように発信しますか？ http://www.postgresql.org/support/submitbug のPostgreSQL バグフォームを訪れてく ださい。バグレポートを提出する仕方についての手引と指針があります。 それと同時に ftp サイト ftp://ftp.postgresql.org/pub/ で、最新バージョンの PostgreSQL を探してみてください。 バグフォームを使ったり、あるいはいずれかのPostgreSQLメーリングリストに投稿した りすると、一般的に以下の項目のどれかが返答の内容となります： ・ バグではない、その理由 ・ 既知のバグで、既にTODOリストに載っている ・ 現行のリリースでバグが直っている ・ バグは直っているが、公式リリースにはまだパッケージされていない ・ さらに詳細な情報の要求: □ オペレーティングシステム □ PostgreSQLのバージョン □ 再発できるテストケース □ デバッグ情報 □ デバッガでのバックトレースの出力 ・ 新たなバグ。次のようなことが起きるかも: □ パッチが作成されていて、次のメジャーあるいはマイナー・リリースに取り込 まれる予定 □ バグはすぐには修正できなくて、TODOリストに追加される 1.9) 既知のバグや未だ無い機能はどうやって見つけますか？ PostgreSQLは拡張されたSQL:2003のサブセットをサポートします。我々のページの TODO リストに、既知のバグや欠落機能や将来計画についての記述があります。 特徴の要求は普通次のいずれかの解答の中にあります： ・ 既にここにある機能は、 TODO リストです ・ 次のような機能は目論まれていません。それは： □ SQL規格に準ずる既存の機能と重複するもの □ コードの複雑性ばかりを高めて、得るものが少ない機能 □ 安全性が確められない機能 ・ 新しい機能は、 TODO のリストに加えられられます。 我々は、PostgreSQL に関して、電子メールで直接対応して TODO リストを最新に更新し てゆくほうがより効果的であることを知っていますので、バグ追跡システムは使いませ ん。現実に、このソフトウェアの中でバグはそれほど長くはい続けませんし、多くのユ ーザに影響するバグは早急に修正されます。 PostgreSQLのリリースで、すべての変更点 、改良点、そして、修正点を知りたければ、 CVS のログメッセージを見てください。リ リースノートにさえ、このソフトウェアに加えられたすべての変更点は網羅されていま せん。 1.10) どのような文書がありますか？ 配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュアル・ページ)お よびいくつかの小さなテスト例題が含まれます。 /docディレクトリをごらんください。 また、マニュアルは、 http://www.postgresql.org/docs/ でオンラインでも閲覧できま す。 [訳注: JPUG 文書・書籍関連分科会で翻訳されたマニュアルもあります。 http://www.postgresql.jp/document/current/ 　 インプレスから、（やや古くなりましたが、） PostgreSQLオフィシャルマニュアルも出版されています。 ] PostgreSQL についての本も数冊あります。そのうちの2冊はオンラインで参照もできま す。 http://www.postgresql.org/docs/books/awbook.html [訳注: この本は、JPUG「PostgreSQL Book翻訳分科会」で翻訳され、 ピアソンから「はじめてのPostgreSQL」として出版されました。 ] および、 http://www.commandprompt.com/ppbook/です。 [訳注: 邦訳は「実践 PostgreSQL」としてオライリージャパンから出版されました。 ] 購入可能な書籍の目録は、http://www.postgresql.org/docs/books/ にあります。中で も最も人気のあるのは、Korry & Susan Douglas による本です。 PostgreSQLの技術情報 の記事も、 wiki にあります。 [訳注: 日本語の書籍等については、日本PostgreSQLユーザ会の、 http://www.postgresql.jp/wg/jpugdoc/ 、 http://www.postgresql.jp/PostgreSQL/references.html や http://www.postgresql.jp/wg/psqltrans/ もごらんください。 ] コマンドラインのクライアントプログラムpsql にも、型、演算子、関数、集約、その他 の情報を調べるために、素晴らしい \d コマンドがいくつかあります。 \? を入力する と利用可能なコマンドが表示されます。 [訳注: 2008年11月18日、PostgreSQL普及のために一般向けの情報を扱う 「Let's Postgres」というポータルサイトがオープンしました。 http://lets.postgresql.jp/ ] 1.11) SQL はどうすれば学べますか？ まず、上記で述べた PostgreSQL についての本を読むことを検討してください。 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://sqlcourse.com http:// www.w3schools.com/sql/default.asp http://mysite.verizon.net/Graeme_Birchall/ id1.html http://sqlzoo.net 等にあります。 [訳注: 日本PostgreSQLユーザ会の日本語の参考文献の紹介ページ http://www.postgresql.jp/PostgreSQL/references.html があります。 堀田倫英氏の「PostgreSQL日本語マニュアル」 http://www.net-newbie.com/ ではオンラインマニュアルの検索ができます。 丸山不二夫氏のUNIX データベース入門 http://www.wakhok.ac.jp/DB/DB.html もオンラインで読むことができます。 Nikkei BP IT Pro にある石井達夫氏の PostgreSQL ウォッチ では毎回新しい情報をとりあげています。 ] 1.12) パッチを提供したり、開発チーム参加するにはどうすればよいですか？ 開発者向けのFAQをごらんください。 1.13) 他のDBMSと比べPostgreSQLはどうなのですか？ ソフトウェアを評価する方法にはいくつかあります。機能と性能と信頼性とサポートと 価格です。 機能(Features) PostgreSQLは、トランザクション、サブクエリ、トリガー、ビュー、外部キー整合性参 照、および、洗練されたロック機構など、大規模商用 DBMSが持つ機能をほとんど持って います。さらに PostgreSQLは、ユーザ定義型、継承、ルール、それから、ロック競合を 縮小するマルチバージョン同時性制御など、商用DBMSも持ち合わせないような機能をい くつか持ち合わせています。 性能(Performance) PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ち ます。ある面ではより早かったり、ほかの面ではより遅かったりします。他のデー タベースに比べた性能は、ふつう +/-10% くらいでしょう。 信頼性(Reliability) 我々は、DBMSの信頼性が高くなくてはその価値が無いことを理解してます。十分テスト して、安定したコードをバグを最小にしてからリリースするように努めてます。それぞ れのリリースは少なくとも1 カ月以上のベータ・テストを行ない、これまでのリリース の履歴が、製品版として安定した堅固なリリースであることを物語っています。この分 野では、他のデータベースと比べても遜色がないことに自信を持っています。 サポート(Support) 我々のメーリングリストは、遭遇するいかなる問題についても解決への手助けをしてく れる、開発者やユーザの大きな集まりへの接点を提供しています。我々は問題の解決を 保証することはできませんが、商用データベースであっても常に解決されるわけではあ りません。開発者や、ユーザ・コミュニティ、マニュアル類、それに、ソースコードな どへ直接アクセスできることによって、PostgreSQLのサポートは、他のDBMS サポートよ りも優れたものとなっています。御要望に答えて、事柄毎の商用サポートなどもありま す（FAQ1.7節をごらんください）。 価格(Price) PostgreSQLの利用は、商用でもオープンソースでもすべて無料です。上記に示してある BSDスタイルの使用許諾に外れない限り、PostgreSQLのコードを制限無く商品に取り込む ことができます。 1.14) PostgreSQLを組み込みに使えますか？ PostgreSQLはクライアント／サーバ・アーキテクチャで設計されていて、クライアント とサーバおよびそれを補助するいろいろなプロセスが別々に走ることが要求されます。 多くの組み込みアーキテクチャはこのような要求をサポート可能です。しかし、お使い になっている組み込みアーキテクチャによっては、データベースサーバがアプリケーシ ョン・プロセスの中で走ることを要求される場合があり、Postgresを使うことはできな いので、軽量のデータベースソリューションを選択すべきです。 1.15) PostgreSQLのメーリングリストの購読をやめるにはどうすればよいですか？また 、電子メールを重複して受け取らないようにするにはどうしますか？ PostgreSQLのMajordomo ページから、PostgreSQLに関する複数のメーリングリストの購 読の開始と中止ができるようになっています。（ログインするためにはMajaordomoから 送られる御本人のパスワードが必要になります。） PostgreSQLnoすべてのメーリングリストでは、返信はメーリングリストとかつ元のメー ルの投稿者へ送られるように構成してあります。これにり利用者は、もっとも迅速にメ ールへの返信を受けられるようになっています。既に直接受け取っているメールを、リ ストから重複して受け取りたくない場合は、Majordomo のChange Settingsページから、 eliminateccをチェックします。また、selfcopyのチェックをはずすことで、自分の送っ たメールのコピーを受け取らないようにもできます。 ユーザ・クライアントの質問 2.1) PostgreSQL にはどんなインターフェースが使えますか？ PostgreSQL のインストールに含まれる物はCと組込み Cのインターフェースだけです。 その他のインターフェースは独立したプロジェクトで、別々にダウンロードされます。 分かれることで、それぞれの開発チームが独自のリリーススケジュールを持つことが許 されます。 PHP のようないくつかのプログラミング言語は、 PostgreSQLのインターフェースを含ん でいます。Perl, TCL, Python, そして、そのほかの利用可能な言語のインターフェース は、http://pgfoundry.org の Drivers/Interfaces の節の中とインターネットの検索で みつけられます。 2.2) PostgreSQL を Web ページと連携させるにはどんなツールがありますか？ データベースを裏に持つ 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 を使い ます。 2.3) PostgreSQL にグラフィカル・ユーザインターフェースはありますか？ 商用とオープンソース開発者によるもの両方で、PostgreSQLには多くのGUIツールが利用 可能で、詳細なリストは、 PostgreSQL GUI ツールについてのコミュニティガイドにて ごらんください。 [訳注: pgAdmin3 はPostgreSQL標準GUI管理ツールで、Windows版(PostgreSQL for Windows) に同梱されています。詳しい情報は、 http://www.pgadmin.org/ にあります。 ] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 管理上の質問 3.1) どのようにすれば /usr/local/pgsql 以外の場所にインストールできますか？ 簡単な方法は、 configure を走らせるときに --prefix オプションを指定することです 。 3.2) 他のホストからの接続はどのように制御しますか？ 既定値では、PostgreSQL は Unix ドメインソケット、または、TCP/IP接続のローカルマ シンからの接続しか許しません。postgresql.conf の中の listen_addresses を修正し 、かつ、$PGDATA/pg_hba.conf ファイルを適切に直し、データベースサーバを再起動し て、ホストベースの認証を有効にしないかぎりは、他のマシンからは接続できないでし ょう。 3.3) より良い性能を得るためには、データベース・エンジンをどのように調整しますか 性能改善の可能性のありそうな主な領域が3つあります： クエリの変更 クエリを修正してより良い性能を得ることを含みます： ・ 式および部分インデックスを含む、インデックスを作成 ・ 複数のINSERTのかわりにCOPYを使用 ・ 複数の文をグループ化し、1つのトランザクションにしてコミットのオーバヘッドを 削減 ・ インデックスからから沢山のロウを取り出すときはCLUSTERを使用 ・ クエリの出力のサブセットを返すためにLIMITを使用 ・ 準備されているクエリを使用 ・ オプティマイザの正確な統計を維持するためにANALYZEを使用 ・ VACUUM または pg_autovacuum の常用 ・ 大きなデータ変更のあるときはインデックスを削除 サーバ構成 postgresql.confの設定のいくつかは性能に影響します。詳しくは、Administration Guide/Server Run-time Environment/Run-time Configuration をごらんください(JPUG サイトの日本語版では、 http://www.postgresql.jp/document/current/html/ runtime-config.html)。 ハードウェアの選定 性能におけるハードウェアの影響は http://www.powerpostgresql.com/PerfList/ およ び、 http://momjian.us/main/writings/pgsql/hw_performance/index.html (JPUGサイ トの日本語版: http://www.postgresql.jp/wg/psqltrans/hw_performance_j.pdf) に述 べられています。 [訳注: JPUG理事長の片岡裕生氏による、「今すぐできるPostgreSQLチューニング」 というコーナーが ThinkIT サイトにあり、実作業の参考になります。 http://www.thinkit.co.jp/free/tech/10/1/1.html ] 3.4) どのようなデバグ機能が使えますか？ サーバ構成変数には、 http://www.postgresql.org/docs/current/interactive/ runtime-config-logging.html に示されるように、多くの log_* があり (JPUGサイトの 和訳は http://www.postgresql.jp/document/current/html/ runtime-config-logging.html )、クエリとプロセスの統計情報を出力することができて 、デバグや性能測定にはとても便利です。 3.5) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？ 既定での制限である 100 のデータベースセッションに達してしまっています。サーバー の同時接続できるバックエンドプロセスの制限値を増やす必要があります。 postgresql.conf の中のmax_connections の値を変更してサーバを再起動することで可 能になります。 3.6) PostgreSQLのアップグレードの手順はどうなりますか？ バージョン番号付けの方針について、更新全般についての解説は http:// www.postgresql.org/support/versioning を、そして、アップグレードについての一般 的な説明は http://www.postgresql.org/docs/current/static/install-upgrading.html をご覧ください。 [訳注： アップグレードについての和訳版は下記にあります。 http://www.postgresql.jp/document/current/html/install-upgrading.html ] [訳注： 原文では、下記の内容は独立したページに移され、削除されています。 新しい機能を盛り込むPostgreSQLのメジャーリリースはだいたい年に1回程度行ないます。 メジャーリリースは、たとえば、8.1から8.2へのように、バージョン番号の1番目か2 番目の部分を増やしてゆきます。 PostgreSQLのメジャーリリースは通常、システムテーブルとデータの内部フォーマット を変更します。これらの変更はたいていは複雑なのでで、データファイルの後方互換性 を維持したりはしません。メジャーアップグレードのためには、データベースのダンプ/ リロードが必要になります。 マイナーリリースは、たとえば、8.1.5 から8.1.6へのように、バージョン番号の3番目 の値を増やします。PostgreSQLチームは、マイナーリリースに対しては、バグフィクス しか行ないません。すべてのユーザは、できるだけ最新のマイナーリリースに更新すべ きです。アップグレードには、常にリスクがつきものですから、PostgreSQLのマイナー 修正リリースでは、頻繁に発生したり、セキュリティに関係したり、データがつぶれる バグだけを修正し、アップグレードのリスクを最小限にとどめます。我々のコミュニティ では、アップグレードするリスクよりも、アップグレードしないリスクのほうが高いと 考えています。 マイナーリリースのアップグレードにはダンプとリストアの必要はなく、データベース サーバを停止して、アップデートされたバイナリをインストールし、サーバをリスター トします。 ] 3.7) PostgreSQLは国毎に最新の夏時間の変更を扱いますか？ PostgreSQLのリリース8.0(8.0.4)以降の夏時間情報 (daylight savings information) は、広く使われている tzdata データベース（zoneinfo データベース、または、 Olson timezone データベースとも呼ばれる）に依存します。 DST法の変更をの影響に対応する ためには、新しい tzdata ファイルセットをインストールして、サーバをリスタートし ます。 すべてのPostgreSQL アップデートリリースには、最新版のtzdata ファイルが含まれて いますので、お使いになっているメジャーバージョンのマイナーリリースのアップデー トを続けていれば通常は十分これに対応できます。 我々のプラットホームは、tzdata ファイルを含む標準のソフトウェアアップデートを受 け取りますが、システムによる tzdata ファイルのコピーに頼るほうがより便利です。 ほとんどのLinuxディストリビューションでは、ビルト済みのPostgreSQLのバージョンに このアプローチが選択されています。 8.0以前のPostgreSQLリリースでは、オペレーティングシステムのtimezone情報を頼りに しています。 3.8) ハードウェアにはどのようなコンピュータを使えばよいですか？ PCハードウェアはほとんど互換性がありますので、ほとんどの人は、すべてのPCハード ウェアが同じ品質だと思い込む傾向があります。しかし、それは間違いです。ECC RAM、 SCSI、および、高品質マザーボードは、安いハードウェアに比べると、より信頼性が高 く、より性能も良いのです。 PostgreSQL はほとんどのハードウェアで稼働しますが、 信頼性や性能が重要な場合は、使用中のハードウェアのオプションについて調査するこ とが賢明です。バッテリーバックアップ付きのキャッシュを持つディスクコントローラ も役に立ちます。我々のメーリングリスト上でもハードウェアオプションのトレードオ フについて議論することができます。 操作上の質問 4.1) 最初の数ロウのみを SELECTするにはどうしますか？ランダムなロウ？ 取得したいロウがほんの数行で、SELECT の実行時に取得するロウの数が分かっていれば LIMIT を使いましょう。インデックスが ORDER BY とマッチすれば、クエリ全体を(丸ご と)実行しなくても済む場合もあります。SELECT する時点でロウの数が不明なら、カー ソルを使って FETCH しましょう。 ランダムにロウをSELECTするには、次の文を使います： SELECT col FROM tab ORDER BY random() LIMIT 1; こちらの、Andrew Gierth氏によるブログエントリご覧になれば、ここでのトピックにつ いてさらに詳しく出ています。 4.2) 定義されたテーブル、インデックス、データベース、および、ユーザをどのように して見つけ出しますか？psqlで使われているクエリを表示するにはどうしますか？ psql の中で \dtコマンドを使ってテーブルを見ることができます。psqlの中で \? を使 って、コマンドの全リストを調べることができます。一方で、psql のソースコードで、 バックスラッシュコマンドを出力する pgsql/src/bin/psql/describe.c ファイルを読む こともできます。その中には、 SQL コマンドを生成する部分も含まれます。また、 -E オプションを付けて psql を開始すると、入力されたコマンドを実行するためのクエリ を印字出力するようになります。 PostgreSQLは SQL 準拠の INFORMATION SCHEMA イン ターフェースを提供しますので、データベースについての情報を問い合わせることもで きます。 pg_ で始まるシステムテーブルでもこれらを記述することができます。 psql -lを使うと全てのデータベースをリストします。 それと、pgsql/src/tutorial/syscat.source を試してみてください。そこには、データ ベースのシステムテーブルから情報を得るために必要な SELECT 文が沢山あります。 4.3) カラムのデータ型を変更するにはどうしますか？ カラムのデータ型の変更は 8.0 以降では、 ALTER TABLE ALTER COLUMN TYPE を使うこ とにより間単になりました。 それより前のバージョンでは、以下のようにします: 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をしたほうが良いかもしれません。 4.4) ロウ、テーブル、データベースの最大サイズは？ 制限は以下のとおりです: データベースの最大サイズ? 制限無し (32 TB のデータベースも存在しま す) テーブルの最大サイズ? 32 TB ロウの最大サイズ? 400 GB フィールドの最大サイズ? 1 GB テーブル内での最大ロウ数? 制限無し テーブル内での最大カラム数? カラムの型によって 250-1600 テーブル内での最大インデックス 制限無し 数? もちろん、これらは実際は無制限ではなく、ディスク容量とメモリーやスワップスペー スの大きさにより制限されます。性能はこれらの値がことのほか大きな時に煽りを受け ます。 最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファイルのサポート は必要としません。巨大なテーブルは複数の1GBのファイルに分けて保存されますので、 ファイルシステムの制限は重要ではありません。 デフォルトのブロックサイズを32kに増加することで、最大テーブルサイズと行サイズと 最大カラム数とを4倍にすることができます。また、最大テーブルサイズはテーブルパー ティションを使って増やすこともできます。 ひとつの制限は、約2,000文字以上の長さのカラムにインデックスを付けることができな いことです。幸いにも、そのようなインデックスは実際は必要ありません。長いカラム のMD5ハッシュの関数インデックスは一意性がなによりの保険で、また、フルテキストの インデックスではカラム内の単語を検索することができます。 4.5) 一般的なテキストファイルのデータを保存するには、データベースのディスク容量 はどのくらい必要です？ 普通のテキストファイルを PostgreSQL のデータベースに保存するには、最大で約5倍の ディスク容量を必要とします。 例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを考えてみましょ う。テキストの文字列の平均長さを20バイトと仮定すると、フラットファイルの大きさ は約2.8MB です。このデータを含む PostgreSQL データベースファイルの大きさは次の ように約5.2MBと見積もることができます： 24 bytes: 各ロウのヘッダ(概算) 24 bytes: 整数(int)フィールドとテキスト(text)フィールド + 4 bytes: ページ上のタップルへのポインタ ---------------------------------------- 52 bytes per row PostgreSQL のデータページサイズは 8192バイト(8KB)なので: 8192 bytes per page ------------------- = 146 rows per database page (切り捨て) 52 bytes per row 100000 data rows -------------------- = 633 database pages (切り上げ) 158 rows per page 633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB) インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされる データを含む以上、それなりに大きくなります。 NULLはビットマップとして保存されていて、それらがわずかにスペースを使います。 long型の値は透過的に圧縮されるかもしれないことに注意します。 トピックに関して、こちらのプレゼンテーションもご覧ください：Image:How Long Is a String.pdf。 4.6) クエリが遅いのはなぜでしょう？なぜ、インデックスが使われないのでしょうか？ インデックスは、すべてのクエリで使われるわけではありません。テーブルが最小サイ ズより大きく、クエリでそのわずかなパーセンテージのロウを選択する時だけ、インデ ックスは使われます。これはインデックススキャンにより起こされるランダムなディス クアクセスは、テーブルをストレートに読むシーケンシャルスキャンよりも遅くなるこ とがあるからです。 インデックスを使うかを決定するために、PostgreSQL はテーブルについての統計情報を 持たなければなりません。この統計情報は、 VACUUM ANALYZEまたは、単に ANALYZE を 使って収集することができます。統計情報を使ってオプティマイザはテーブルの中にあ るロウ数を知り、インデックスを使うべきかの決定をより正しくできます。統計情報は 最適な結合順や結合方法を決める上でも貴重なものもあります。統計情報の収集は、テ ーブルの内容が変わる毎に繰返しなされるべきです。 インデックスは、通常 ORDER BY や結合を行なうためには使われません。シーケンシャ ルスキャンに続く明示的ソートは、巨大なテーブルのインデックススキャンよりも普通 は高速です。 しかし、ORDER BYと組み合わされたLIMIT は、テーブルの小さな部分を返すためにたび たびインデックスを使うでしょう。 もし、オプティマイザが間違ってシーケンシャルスキャンを選択したことに疑いがなけ れば、SET enable_seqscan TO 'off'に設定して、クエリをもう一度実行し、インデック ススキャンがまちがいなく速くなっているかどうかをみてください。 LIKE あるいは ~ のようなワイルドカード演算子は特別な環境でしか使えません： ・ 検索文字列が文字列の最初にききます。たとえば： □ LIKE パターンが %、あるいは、_ で始まらない □ ~ (正規表現) パターンは ^ で始まらなければならない ・ 検索文字列を文字クラスから始めることはできません。たとえば、[a-e]。 ・ ILIKE や ~* のような大文字と小文字を区別しない検索は使えません。そのかわり 、このFAQの 4.8節で説明する式インデックスが使えます。 ・ initdb においては、デフォルトの C ロケールを使わなくてはなりません。その理 由は、C ロケール以外では、LIKE の振る舞いに合致しないことが多々あるからです 。このような場合に働くような、特別な text_pattern_ops でインデックスを作成 することもできますが、それは、LIKE インデックス作成にだけしか役に立たちませ ん。 フルテキスト・インデクシングを単語検索に使うことも可能です。 4.7) 問い合わせオプティマイザがどのように問い合わせを評価するのかを見るにはどう しますか？ EXPLAINコマンドでこれをするには、Using EXPLAIN を見てください。 4.8) テキスト形式の並び替え順を変更するにはどうしますか？ PostgreSQLはテキスト形式データの並び替えを、initdbの際に選択した現行のロケール により定義されている順番にしたがって行います。 (8.4以降では、データベースを作成 するときにロケールを選ぶことができるようになりました。）並び替えが好きでなけれ ば、他のロケールを使う必要があります。得に、"C" 以外のロケールでは、辞書の順番 にしたがって並び替えが行われ、句読点や空白は無視されます。もし、そうしたくなけ れば、 "C" ロケールの必要があります。 4.9) 正規表現での検索や大文字と小文字とを区別しない正規表現検索はどのように実現 しますか？大文字と小文字とを区別しない検索のためのインデックスはどのように使い ますか？ ~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない (case-insensitive)正規表現照合を行います。大文字と小文字を区別しない LIKE 演算 子を ILIKE といいます。 大文字と小文字を区別しない等値比較は次のように表現できる： SELECT * FROM tab WHERE lower(col) = 'abc'; ここでは、"con"に張られた標準インデックスは使われませんが、もし、"lower(col)"の 式インデックスを作成すれば、それが使われます。 CREATE INDEX tabindex ON tab (lower(col)); 上記のインデックスがUNIQUEで作成された場合、カラムは大文字と小文字を格納できま すが、その違いが大文字と小文字の違いだけであっても同一にはなりません。あえて特 定の文字ケースをカラムに格納するには CHECK制約か、トリガーを使ってください。 PostgreSQL 8.4 以降では、貢献による CITEXT データ型を使うこともでき、内部で "lower()" 呼び出しを実装していますので、まったく大文字小文字を区別しないでそれ を効果的に扱うことができます。 CITEXT は8.3用にも利用可能であり、pgFoundryにあ る初期のバージョンでは、8.2 でもASCII文字のみであれば、大文字小文字を区別しない 取扱いができます。。 4.10) クエリの中で、フィールドがNULL であることを検出するにはどうしますか？ NULLであることを検出するにはどうしますか？フィールドがNULLかどうかでどのように ソートができますか？ 以下のように、IS NULL と IS NOT NULLで、その値をテストできます： SELECT * FROM tab WHERE col IS NULL; NULLをその他のものと連結するとNULLになります。そうしたくなければ、COALESCE()を 次のように使い、NULLを置き換えます。 SELECT COALESCE(col1, '') || COALESCE(col2, '') FROM tab; NULL状態でソートするには、IS NULL と IS NOT NULL の修飾子を ORDER BY 句の中で使 います。true のものは false のものよりも高い値として並べられますので、次の例で は NULL の記載が出力の前に置かれます。 SELECT * FROM tab ORDER BY (col IS NOT NULL), col; PostgreSQL 8.3 以降では、NULLの並び替え順番を、最近規格化された NULLS FIRST/ NULLS LAST 修飾子を使って、次のように制御できます： SELECT * FROM tab ORDER BY col NULLS FIRST; 4.11) いろいろな文字型のそれぞれの違いは何ですか？ ┌──────────┬────┬─────────────────────┐ │ 型 │ 内部名 │ 備考 │ ├──────────┼────┼─────────────────────┤ │VARCHAR(n) │varchar │最大長のサイズを指定する、詰め物無し │ ├──────────┼────┼─────────────────────┤ │CHAR(n) │bpchar │指定された固定長となるように空白が詰められ│ │ │ │る │ ├──────────┼────┼─────────────────────┤ │TEXT │text │長さに特別な上限は無し │ ├──────────┼────┼─────────────────────┤ │BYTEA │bytea │可変長のバイト配列(nullバイト可) │ ├──────────┼────┼─────────────────────┤ │"char" (クォート付 │char │1バイト │ │き) │ │ │ └──────────┴────┴─────────────────────┘ 内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを 受け取るときです。 上記の型のうち最初の４つの型は "varlena" 型です(すなわち、フィールド長が明示的 にディスクに保存され、それの後に実際のデータが続きます)。このように実際の空間は 期待された大きさよりも少し大きくなります。しかし、長い値は圧縮されるので、ディ スク上の空間は思ったよりも小さくなります。 文字列長さの上限値が指定のアプリケーションにより要求される場合は、VARCHAR(n) は 可変長の文字列を保存するのに最適です。 TEXT は "無制限の"長さの文字列のためのも のです（PostgreSQL ではすべてのフィールドを通して、最大の値の長さは1ギガバイト に制限されています）。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込ん でいつも同じ長さで文字列を保存するのに最適です。BYTEAは、バイナリデータを保存し 、特別に0バイトの値を含むます。これらの３つの型は、CHAR(n)によるブランクパディ ングが追加のストレージと余計なランタイムを要求することを除けば、同じような性能 特性をもちます。 "char" 型（CHAR(n)と識別するためにクォートが必要）は、正確に1バイトのみを格納す るデータ型のために得に用意されました。それは、システムカタログに見ることができ ますが、ユーザテーブルで使用することはお勧めしません。 4.12) 通番(serial)／自動増分フィールドはどのようにつくりますか？ PostgreSQL は SERIAL データ型をサポートします。現実には、これは実際の型ではあり ません。それは、連番を食わせられる整数カラムを作る省略形です。たとえば、 CREATE TABLE person ( id SERIAL, name TEXT ); は自動的に次のように翻訳されます: CREATE SEQUENCE person_id_seq; CREATE TABLE person ( id INTEGER NOT NULL DEFAULT nextval('person_id_seq'), name TEXT ); [訳注： CREATE UNIQUE INDEX person_id_key ON person ( id ); は、 7.3 以降は自動的には行なわれなくなりました。 ] 自動的につくられる通番は、 table_serialcolumn_seq と名付けられていて、table と serialcolumn は、それぞれテーブルと SERIAL カラムの名前です。通番については、オ ンラインマニュアルでCREATE SEQUENCE をごらんください。 BIGSERIALというのもあり、SERIALのようで、結果としてカラムの型が INTEGER のかわ りに BIGINT になります。テーブルを使いつづける上で、20億以上の通番が必要と思わ れる場合には、この型を使います。 4.13) SERIALデータ型に挿入される値は、どうすれば得られますか？ 最も簡単な方法は、割り当てられたSERIAL値を RETURNINGとして取得することです。ひ とつ前の例題テーブルを使うと次のようになります。 INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id; nextval()を呼び出して、その値をINSERTで使うか、INSERTの後で curval()を呼び出し てもかまいません。 4.14) currval() によって他のユーザと競合状態に陥ることはないですか？ それはありません。currval() は、他のユーザのセッションで起きていることとは独立 に、そのユーザのセッションで与えられた最新の連番値を返します。 4.15) シーケンス／SERIALカラムへの割り当て番号にギャップがあるのはなぜですか？ トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜで すか？ 同時接続性を改善するために、必要に応じてトランザクションに連番（シーケンス値） を与えています。実行中のトランザクションが終了するまでシーケンスの対象がロック され続けられないように、他のトランザクションでは他のシーケンスが直ちに割り当て られるようにしています。このため、トランザクションが中断されたときには割り当て 番号に飛び（ギャップ）が発生します。 4.16) OID とは何ですか？ テーブルがWITH OIDSでつくられた場合は、それぞれのロウは、INSERTの際に自動的に詰 め込まれる、OIDカラムを含みます。 OIDは順番に与えられた4バイトの整数です。最初 は、全インストレーションを通して一意な値です。しかし、OIDは約40億で一巡し、その 後、OIDは重複します。 OIDカラムに一意の（ユニーク）インデックスを作ることで、一つのテーブル内でのOID の重複は避けることができます（しかし、WITH OID句ではこれができないことに注意し ましょう）。システムはインデックスをチェックし、新たに生成するOIDが既に提供され ている場合は、新しいOIDの生成を繰り返します。OIDを含むテーブルがおおよそ40億行 を越えないかぎりは、これでうまくゆきます。 PostgreSQLはシステムカタログの中でオブジェクトの識別子にOIDを使いますが、大きさ の制限が問題になるのは仕方がありません。 ユーザのテーブルのカラムに一意となるように番号付けをするるためには、 OID ではな く SERIAL を、あるいは、テーブルが運用中に20億行を越えることが予想される場合は BIGSERIAL を使うのが最善です。 4.17) CTID とは何ですか？ CTID は、テーブル内で、特定の物理ロウをブロックとオフセットの値で識別するために 使われます。 CTIDは、物理ロウを指し示すためのインデックスの記載に使われます。し かし、時によって、競合する更新が予期されないときは、トランザクションの中でロウ を識別するためにも役に立ちます。 4.18) エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはな ぜですか？ おそらく、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、 カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。サーバを始 動する前にこれを試してみてください： ulimit -d 262144 limit datasize 256m シェルによって、どちらかひとつが成功するでしょうが、これはプロセスのデータセグ メント制限をより高く設定し、たぶんクエリが完結するようになるでしょう。このコマ ンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスに ついて適用されます。バックエンドがとても多くのデータを返すためにSQL クライアン トで問題が続いているのであれば、クライアントを開始する前にこれを試してみてくだ さい。 4.19) どのバージョンの PostgreSQL を走らせているかを調べるにはどうしますか？ SELECT version(); クエリを走らせます。 4.20 データベース操作の監査証跡を残す方法はありますか? 何も組み込まれていませんが、そうした機能を組み立てることがとても難しいわけでは ありません。 簡単な例は公式文書にもあります： http://www.postgresql.jp/document/current/html /plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE この機能を標的とするプロジェクト： http://pgfoundry.org/projects/tablelog/ 背景となる知識やその他の実装： http://it.toolbox.com/blogs/database-soup/ simple-data-auditing-19014 http://www.go4expert.com/forums/showthread.php?t= 7252 http://www.alberton.info/postgresql_table_audit.html 4.21) 現在の時刻がデフォルトとなるようなカラムはどのようにつくりますか？ CURRENT_TIMESTAMPを使います: CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); 4.22) 外部結合(outer join)はどのように実現しますか? PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポートします。こ こに 2つの例題があります。 SELECT * 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結合と呼ばれます。 4.23) 複数のデータベースを使う問い合わせはどのようにすればできますか？ 現行のデータベース以外への問い合わせの方法はありません。というのもPostgreSQLが データベース仕様のシステムカタログを読み込むためで、そこには、たとえそのふりを するだけにしろ、データベースを越えて問い合わせをするすべがありません。 contrib/dblink はデータベース間(cross-database)の問い合わせを関数呼出しにより許 します。もちろん、クライアントは同時に接続を別のデータベースへも張らなくてはな らず、結果をクライアント側でマージしなくてはなりません。 4.24) 関数から複数のロウまたはカラムを返すにはどうしますか？ 集合を返す関数(Set Returning Functions): Return more than one row of data from PL/pgSQL functions を使うと簡単です。 4.25) PL/PgSQL の関数の中で一時テーブルにアクセスするとき、どうして "relation with OID ##### does not exist" というエラーを受け取るのでしょうか？ バージョン8.3より前の PostgreSQL では、PL/PgSQL は関数スクリプトをキャッシュし たため、運悪くその副作用がありました。PL/PgSQL 関数が一時テーブルにアクセスして 後でそのテーブルを消して作りした場合に、関数がもう一度呼び出されたときは、その 関数のキャッシュしていた内容がまだ古い一時テーブルを指し示したままだったからで す。この、解決策として、PL/PgSQLの中で EXECUTE を一時テーブルへのアクセスのため に使います。そうすると、クエリは毎回パースをやり直しされるようになります。 この問題は、 PostgreSQL バージョン8.3 以降では起きません。 4.26) どのようなレプリケーションのソリューションがありますか？ 「レプリケーション」と一言でいいますが、レプリケーションをするための技術はいく つもあり、それぞれ、利点と欠点があります。このトピックについて、我々の文書のこ ちらにも良い紹介が含まれています http://www.postgresql.jp/document/current/html /high-availability.html 。また、レプリケーションソフトウェアとその機能について 格子状にまとめたものがこちらにあります Replication, Clustering, and Connection Pooling 。 マスタ／スレーブのレプリケーションは、読み／書きのクエリを受け取るシングルマス タが可能で、スレーブでは読み／SELECTの問い合わせだけを受け付けることができます 。最も人気がある、フリーで利用できる、マスタ-スレーブのPostgreSQLレプリケーショ ンソリューションは、 Slony-I です。 マルチ-マスタのレプリケーションは、読み／書きのクエリを受けとり、複数のレプリケ ートさせるコンピュータに送ることができます。この機能は、サーバ間の変更の同期が 必要なため、性能に重大な衝撃を与えます。 PGCluster は、このようなソリューション としてPostgreSQLのためにフリーで利用できるものとして、最も人気があります。 この他にも、商用やハードウェアベースのレプリケーション・ソリューションが利用可 能で、いろいろなレプリケーションのモデルをサポートしています。 4.27)テーブルとカラムの名前がクエリーの中で認識されないのはなぜですか？なぜキャ ピタライズ(単語先頭の大文字化)は保持されないのですか? 名前が認識されない最も一般的な原因は、テーブルを作成する際に、テーブルやカラム を囲う二重引用符の使用です。二重引用符を使うと、テーブルとカラムの名前（識別子 といいます）は大文字と小文字の区別をして格納されます。したがって、pgAdminのよう にテーブル作成のときに自動的に二重引用符を使うものはクエリの中でそれらの名前を 使うときに二重引用符を付けなくてはならないことを意味します。このため、識別子を 認識させるためには以下のいずれかを心がけます。 ・ テーブルを作成するときに二重引用符で識別子を囲うことを避ける ・ 識別子には小文字だけを使う ・ クエリの中で参照するときは二重引用符で識別子を囲う 4.28)データベースのパスワードを忘れてしまいました。取り戻すにはどうしますか？ できません。しかし、設定をやり直したりすることはできます。これをするには、 ・ pg_hba.conf を編集して、一時的に trust 認可を許します ・ 構成ファイルをリロードします (pg_ctl reload) ・ 接続して ALTER ROLE / PASSWORD を新しいパスワードを設定するために発行します ・ pg_hba.conf を再び編集し、元の設定に戻します ・ 構成ファイルを再びリロードします 4.29)PostgreSQLにストアードプロシージャはありますか？ PostgreSQLにストアドプロシージャはありませんが、とても強力な関数を持っていて、 ユーザ定義関数の機能をつかって、他のDBMSのストアードルーチン(プロシージャや関 数)でできるような大抵の能力は持ってますし、多くの場合はそれ以上のこともできます 。 これらの関数は、違う型であっても、いくつかのプログラミング言語で実装することが できます。 (詳しくは次の文書を参照ください。 User-Defined Functions) PostgreSQL の関数はいろいろな方法で呼び出せます。他のRDBMSの中のストアドプロシ ージャを呼び出すように関数を呼び出したい場合は(一般的に関数は副作用がありますが 、その結果については気にしないようにするには、たとえば、戻りをvoid型にすること で)、ひとつのオプションとしては、プロシージャを PL/pgSQL 言語で書いて PERFORM コマンドを使うことです。たとえば、次のとおりです。 注意: SELECT theNameOfTheFunction(arg1, arg2); の代わりに、 PERFORM theNameOfTheFunction(arg1, arg2); とすれば、関数はvoidを返すとしても(この結果はvoid値を含む1レコードとなりますが) 、結果は生成されます。 PERFORM は、このように使うことができて無用な結果を破棄することができます。 日本語に関する質問 5.1)日本語がうまく扱えないのはなぜですか？ createdb -Eコマンドオプションに UTF8 あるいは EUC_JP のエンコーディングを指定し てデータベースを作成するか、次のようにエンコーディングを指定してデータベースを 作成してください。 CREATE DATABASE dbname WITH ENCODING 'UTF8'; もしくは、 CREATE DATABASE dbname WITH ENCODING 'EUC_JP'; 5.2) psql でWindowsからアクセスしたときに、日本語が文字化けするのですが？ psqlの中でクライアントのエンコーディングを指定してください。 SET client_encoding TO 'SJIS' PostgreSQLデータベースのエンコーディングに使える日本語文字コードは EUC_JP か UTF-8(UNICODE) であるため、Shift-JIS表示のコマンドプロンプトからは、 client_encodingを設定しておかないと、日本語を表示する際に文字化けがおきます。 5.3) PostgreSQLで日本語の全文検索はできますか？ バージョン8.3では、TSearch2全文検索機能が本体に組み込まれましたが、そのままでは 日本語のインデックスを作る事が難しい状況です。これを解決するために、Takahiro Itagaki氏によって、Mecabという形態素解析プログラムを利用する日本語全文検索モジ ュール (textsearch-ja) で日本語対応できます。最新の mediawiki などでは、 postgresql.conf で default_text_search_config = 'pg_catalog.japanese' を設定して使うことができます。 Drupal CMSフレームワーク用には、開発中の drupal-tsearch モジュールが github.com にあります。 「日本語版について」 [訳注： 日本語版の製作については以下の通りです。 最終更新日: 2010年1月11日 翻訳者: 桑村 潤 (Jun KUWAMURA ) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): 田仲 稔 石井 達夫 齊藤 知人 馬場 肇 岡本 一幸 小菅 昭一 山下 義之 境 真太郎 生越 昌己 石川 俊行 本田 茂広 せせ じゅん 神谷 英孝 菅原 敦 稲葉 香理 芳賀 靖史 板垣 貴裕 をはじめ、ポストグレスに関する話題豊富な日本語PostgreSQLメーリングリスト、 和訳のきっかけを作ってくれたり、いつもチェックをしてくださる JF(Linux Japanese FAQ)プロジェクト、FreeBSD ドキュメンテーションプロジェクト の方々、それから、直接あるいは間接的にかかわってくださるすべてのオープンソース コミュニティのみなさまに感謝いたします。 この翻訳文書は 本家Wiki-日本(http://wiki.postgresql.org/wiki/Japanese) のページ、 日本語トピックのところに "FAQ/ja" という項目であります。 また、以下のサイトにもあります。 http://www.postgresql.jp/wg/jpugdoc/ 「JPUG文書・書籍関連分科会」 http://www.linux.or.jp/JF/JFdocs/INDEX-database.html 「Linux JFプロジェクト」 http://www.linet.gr.jp/~juk/pgsql/ 「PostgreSQL Notes for Japanese」（翻訳者ページ） ]