FAQ/ja

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

原文最終更新日: 31 July 2015‎

特定プラットホームの質問

WindowsユーザはWindowsユーザ向けFAQも参照してください。また、プラットフォーム固有のFAQ も参照してください。

一般的な質問

PostgreSQL とは何ですか？その呼び方は？ Postgresとは？

PostgreSQLはPost-Gres-Q-L(ポスト・グレス・キュー・エル) と発音しますが、会話の中では単純にPostgres（ポストグレス）と呼ばれることもあります。（"PostgreSQL"をどう発音するかが気になる人のために、音声ファイルを用意してあります。

PostgreSQL は、オブジェクト-リレーショナルデータベースシステムで、伝統的な商用データベースシステムに、次世代DBMSシステムに見られるような改良が施された特徴を有します。PostgreSQLは、自由に完全な形でそのソースコードを手に入れることができます。

PostgreSQL の開発は、ほとんどが、世界中にひろがったボランティアの開発者によって、インターネットを通したコミュニケーションによって行われています。コミュニティによるプロジェクトであるため、どの企業の制御もうけません。開発に参加したければ、開発者向けのFAQ を見てください。

Postgresは、広く使われているPostgreSQLの愛称です。また、この名前は、バークレーでのプロジェクトで元々使われていた名前で、ほかのいずれの愛称に比べても遥かに好ましいものです。'PostgreSQL' の発音が難しいと思われるなら、そのかわりに 'Postgres' と呼ぶようにしましょう。

誰が PostgreSQL をコントロールしていますか？

PostgreSQLの門番、中央委員会、あるいは、コントロールをする会社を探そうとしても、諦めざるをえず ---- 存在しないのです。我々は、中心となるコミッティとCVSコミッタを持ちますが、これらのグループはコントロールするためというよりも、管理上のものです。ここでは、プロジェクトは、だれでも参加ができる開発者とユーザのコミュニティにより方向付けられます。読者がやらなければならないことは、メーリングリストをサブスクライブして、議論に参加することです。（開発者向けのFAQには、PostgreSQLの開発への加わり方についての情報があります。）

誰が PostgreSQL Global Development Group ですか？

"PGDG"は全世界的な、個人とPostgreSQLプロジェクトへ貢献する企業からなる非法人組織です。 PostgreSQLのコアチームは一般的にPGDGの代表者として行動します。

PostgreSQL コアチームとは何ですか？

PostgreSQLプロジェクトの以下の取り決めを行う5名から7名（現在は6名）の上級貢献者の委員会です： (a)リリース日の決定 (b)プロジェクトの機密事項の処理 (c)必要に応じてPGDGの代表としての行動 (d)合意が取れていないコミュニティの決定事項の仲裁

現在のコアチームは貢献者のページの最上位に掲載されています。

いくつかの PostgreSQL 基金については？

PostgreSQLプロジェクトは、アメリカ、ヨーロッパ、ブラジル、日本にて募金及びプロジェクトの調整のために非営利団体を活用していますが、これら団体はPostgreSQLのソースコードを有していません。

PostgreSQL のライセンスはどうなっていますか？

PostgreSQL は下記のラインセンスに従います。

PostgreSQLはBSDやMITに似たライセンスの下で配布されています。それは基本的には、利用者がそのコードを好き勝手に利用することが許されています。制限があるとすれば、このソフトウェアに伴ういかなる問題においても法的に責任を我々に負わせることができないということです。また、この著作権表示がこのソフトウェアのすべての複製に表示することも必要です。以下に、我々が使っているライセンス（使用許諾書）を示します：

   [訳注：
       正文は英語です。参考として、訳文を併記掲載します。
   ]

PostgreSQL Database Management System
(formerly known as Postgres, then as Postgres95)

Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group

Portions Copyright (c) 1994, The 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-2011, PostgreSQL国際開発グループ
       部分的著作権 (c) 1994-1996 カリフォルニア大学本校


         本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章
       およびこれに続く二つの段落が全ての複製に添付されている限りにおい
       て、使用、複製、修正および配付の許可を、いかなる目的であっても、
       無償でかつ同意書無しに行なえることをここに認めます。

         カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を
       含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた
       損害について、たとえカリフォルニア大学がこれらの損害について訴追
       を受けていたとしても、一切の責任を負いません。

         カリフォルニア大学は、商用目的における暗黙の保証と、特定目的で
       の適合性に関してはもとより、これらに限らず、いかなる保証も放棄す
       ることを明言します。以下に用意されたソフトウェアは「そのまま」を
       基本原理とし、カリフォルニア大学はそれを維持、支援、更新、改良あ
       るいは修正する義務を負いません。

   [訳注：
       著作権に関する正文は上記の英語による表記です。日本語訳はあくまで
       参考程度としてください。
   ]

PostgreSQLをサポートするプラットホームは？

一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働させられるはずです。最近、実際にテストを行なったことの報告がなされたプラットホームについては、ビルドファームで見ることができます。サポート・プラットホームについてさらに詳しいことは、http://www.postgresql.org/docs/current/static/supported-platforms.html の文書にあります。

PostgreSQL は、Windows XP、Vista、7、8、2003、2008 など Microsoft Windows NTベースのオペレーティングシステムで、ネイティブに走ります。あらかじめパッケージにされたインストーラが http://www.postgresql.org/download/windows からダウンロードできます。

Windows向けのCygwinビルドが存在しますが、一般的に推奨されません；代わりにWindowsネイティブビルドを利用してください。クライアントアプリケーション向けにCygwinが本当に必要であれば、WindowsネイティブPostgreSQLへ接続するためにクライアントライブラリ（libpq）のCygwinビルドが利用可能です。

   [訳注
       日本語での情報は、次の Windows版に関するFAQの和訳をごらんください。
        Running & Installing PostgreSQL On Native Windows/ja
   ]

PostgreSQL はどこから入手できますか？

いくつかのオペレーティングシステムとプラットホーム向けにバイナリ配布があります；我々のダウンロードページをご覧ください。ソースコードは、Webブラウザ経由または、 ftp経由で取得できます。

最新のリリースはどれですか？

PostgreSQL の最新リリース版は、我々のWebサイトで見ることができます。我々は、1年毎にメジャーリリースを、数ヵ月ごとのマイナーリリースを行なうことを原則としています。通常、マイナーリリースは、すべてのメジャーリリースのブランチについて同時に行われます。メジャーリリースとマイナーリリースについて詳しくは、http://www.postgresql.org/support/versioning をご覧ください。

   [訳注
       バージョン番号の x.y.z の最初の x.y がメジャーリリースの番号に相
       当し、最後の z がマイナーリリースの番号になります。メジャーリリー
       スの番号が同じであれば、データベース・クラスタに互換性があります。
   ]

サポートはどこで受けられますか？

PostgreSQL コミュニティは多くのユーザのために、電子メール経由の支援を提供しています。電子メールリストをサブスクライブするためのメインとなるウェブサイトは http://www.postgresql.org/community/lists/ です。これから、始めるのであれば general または、bugs といったリストがよいでしょう。コツとしては、他者からの支援を受けるために十分な情報が含まれているか、念のため投稿前にguide to reporting problemsを読むことを検討してください。

メジャーなIRC チャンネルは、Libera (irc.libera.chat)の #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 にあります。

バグレポートはどのように発信しますか？

http://www.postgresql.org/support/submitbug のPostgreSQL バグフォームを訪れてください。バグレポートを提出する仕方についての手引と指針があります。

それと同時に ftp サイト ftp://ftp.postgresql.org/pub/ で、最新バージョンのPostgreSQL を探してみてください。

回答を促したり回答する手助けとなるように、あなたのレポートにて完全に理解及び再現できるための情報が含まれているか、確認するためにguide to reporting problemsを読むことが重要です。

バグフォームを使ったり、あるいはいずれかのPostgreSQLメーリングリストに投稿したりすると、一般的に以下の項目のどれかが返答の内容となります：

バグではない、その理由
既知のバグで、既にTODOリストに載っている
現行のリリースでバグが直っている
バグは直っているが、公式リリースにはまだパッケージされていない
さらに詳細な情報の要求:
- オペレーティングシステム
- PostgreSQLのバージョン
- 再発できるテストケース
- デバッグ情報
- デバッガでのバックトレースの出力
新たなバグ。次のようなことが起きるかも:
- パッチが作成されていて、次のメジャーあるいはマイナー・リリースに取り込まれる予定
- バグはすぐには修正できなくて、TODOリストに追加される

既知のバグや未だ無い機能はどうやって見つけますか？

PostgreSQLは拡張されたSQL:2008のサブセットをサポートします。我々のページの TODOリストに、既知のバグや欠落機能や将来計画についての記述があります。

機能の要求は普通、次のいずれかの解答がなされます：

その機能は、 TODO リストに存在します
その機能は望ましくありません。それは：
- SQL規格に準ずる既存の機能と重複するもの
- コードの複雑性ばかりを高めて、得るものが少ない機能
- 安全ではない又は信頼性の低い機能
新しい機能は、 TODO のリストに加えられます

我々は、PostgreSQL に関して、電子メールで直接対応して TODO リストを最新に更新してゆくほうがより効果的であるため、バグ追跡システムは使用していません。現実に、このソフトウェアでは長期間存在しつづけるバグがなく、多くのユーザに影響するバグは早急に修正されます。 PostgreSQLのリリースで、すべての変更点、改良点、そして、修正点を知りたければ、 CVS のログメッセージを見てください。リリースノートにさえ、このソフトウェアに加えられたすべての変更点は網羅されていません。

私が遭遇したバグが PostgreSQL の新たなマイナーリリースにて解決されていますがアップグレードしたくありません。この問題のパッチを入手できますか？

いいえ、できません。誰もあなたのために独自のパッチを作成しませんが、解決されたバージョン（例：8.4.3）を展開し、未解決のバージョン（例：8.4.1）に対して適用する（と言う）ことができます。そうする必要が無いからです。もし本当に未解決バージョンに適用する必要があると感じているなら、自分自身でソースからパッチを展開し、適用してください。

PostgreSQLは、バグフィックスのみをポイントリリースにバックパッチするために厳格なポリシーであるバージョンポリシーが存在します。例えば、8.4.1から8.4.3にアップグレードするのが安全です。バイナリの互換性は維持されており、dumpやreloadは要求されず、何も破壊されませんが、問題を起こすバグは解決されます。最悪の場合、バグの解決がアップデート後にREINDEXを要求するかもしれませんが、この場合はリリースノートに記載されます。特定のバグに遭遇していない場合でも、直近で遭遇した場合、即座にアップグレードすることが賢明です。アップデートのインストールとデータベースサーバの再起動が必要となります。リリースノートを読むことが賢明ですが、まれに何か特別な行為が必要となります。

8.3から8.4又は8.4から9.0へのアップグレードは、同様の保障が得られないメジャーアップグレードです。しかしながら、9.0にバグが発見された場合、通常は8.4や8.3のような、すべての維持された古いバージョンに対して安全で実用的であればバックパッチされます。

これは、もしあなたが8.1.0を利用中の場合、8.1.21にアップグレードすることは強く推奨され、とても安全であることを意味します。他方では、次のメジャーリリースである8.2.xにアップグレードすることは、あなたのアプリケーションの変更を要求する可能性があり、dumpやreload又は（8.4以上では）pg_upgradeを確かに要求します；PostgreSQLクラスタのアップグレード処理にオプションの文書がありますので参照してください。

もしすべてのアップグレードについて慎重さを望む場合、あなたのカレントバージョンから同一メジャーリリースの最新のマイナーバージョンまでのリリースノートを注意深く読んでください。もしあなたがアップグレードに対して非常に疑り深い場合、それぞれのポイントリリースのソースコードのセットをPostgreSQLのgitリポジトリから取得し、調査できます。

   [訳注:
         2016年4月8日現在、最新バージョンは9.5.1です。
       和訳されたリリースノートは以下となります。
               https://www.postgresql.jp/document/current/html/release.html
   ]

最新のマイナーリリースに常にアップグレードすることを強く推奨します。ポイントリリースから個々の修正を展開したり適用することを試さないでください；そうすることによって、リリース比較時のPostgreSQLチームによってなされたすべてのQAを無視し、誰にも使用されることのない自身の独自バージョン作り出します。最新の試験された、安全なリリースのものにアップデートするほうがより安全です。独自のパッチを行うこと、非標準ビルドはより多くの時間と努力が必要となり、通常のアップグレードと同様の停止時間を要求するでしょう。

PostgreSQL x.y.1を要求するプログラムがあります。 PostgreSQL x.y.2 を代わりに使用可能でしょうか？

8.4.1のような、特定のバージョンで動作するプログラムは、同一メジャーバージョンのいかなるマイナーバージョンでも動作するはずです。これは、あるプログラムが例えば8.4.1を要求する場合、8.4シリーズの最新バージョンを代替してインストール可能です。

もしアプリケーションの開発元が違うことを言うようであれば、このFAQに誘導し、それでも納得しない場合はpgsql-generalメーリングリストに連絡してもらえれば、われわれが彼らとコンタクトを取ることができます。ユーザに古いマイナーリリースにとどまらせることを強要することはセキュリティやデータの完全性の面から脅威となります。

前の質問に詳細が書かれているので参照してください。

どのような文書がありますか？

PostgreSQLの配布物には巨大なマニュアル、オンライン・マニュアル(マニュアル・ページ)、およびいくつかの小さなテスト例題を含む多くの文書が含まれています。/docディレクトリを参照してください。また、マニュアルは、 http://www.postgresql.org/docs/ でオンラインでも閲覧できます。

   [訳注:
       JPUG 文書・書籍関連分科会で翻訳されたマニュアルもあります。
       http://www.postgresql.jp/document/current/

       インプレスから、（やや古くなりましたが、）
       PostgreSQLオフィシャルマニュアルも出版されています。
   ]

PostgreSQL についての本も数冊あります。購入可能な書籍の目録は、http://www.postgresql.org/docs/books/ にあります。中でも最も人気のあるのは、Korry & Susan Douglas による本です。そのうちの2冊はオンラインで参照もできます。

   [訳注:
       2016/04/26現在、オンライン参照可能な書籍は1冊です。
       題名は「Practical PostgreSQL (O'Reilly Unix)」です。
       邦訳は「実践 PostgreSQL」としてオライリージャパンから出版されました。
   ]

PostgreSQLの技術情報の記事も、 wiki にあります。

   [訳注:
       日本語の書籍等については、日本PostgreSQLユーザ会の、
         http://www.postgresql.jp/wg/jpugdoc/ 、
         http://www.postgresql.jp/wg/psqltrans/
       もごらんください。
   ]

コマンドラインのクライアントプログラムpsql にも、型、演算子、関数、集約、その他の情報を調べるために、いくつかの \d コマンドがあります。 \? を入力すると利用可能なコマンドが表示されます。

   [訳注:
       2008年11月18日、PostgreSQL普及のために一般向けの情報を扱う
       「Let's Postgres」というポータルサイトがオープンしました。
          http://lets.postgresql.jp/
   ]

SQL はどうすれば学べますか？

まず、上記で述べた PostgreSQL についての本を読むことを検討してください。 The Practical SQL Handbook, Bowman Judith S. et al., Addison-Wesley も多くのユーザに好評です。ほかでは、The Complete Reference SQL, Groff et al., McGraw-Hill も好評です。

多くの人はPosgreSQLの実装はもちろん、PostgreSQLの文書が自身でSQLを学習するための素晴らしい参考書となると考えています。こつとしては、学習用に別のフル機能を持ったSQLデータベースと共にPostgreSQLを使用することです。そうするとPostgreSQLの独自機能に依存することなしにSQLに慣れることができます。PostgreSQLの文書は、一般的に標準のPostgreSQLの拡張機能について言及しています。

多くの良質な手引書はオンラインにも存在します：

   [訳注:
        堀田倫英氏の「PostgreSQL日本語マニュアル」
               http://www.net-newbie.com/
       ではオンラインマニュアルの検索ができます。
        丸山不二夫氏のUNIX データベース入門
               http://www.wakhok.ac.jp/DB/DB.html
       もオンラインで読むことができます。
        Nikkei BP IT Pro にある石井達夫氏の PostgreSQL ウォッチ
       では毎回新しい情報をとりあげています。
   ]

パッチを提供したり、開発チーム参加するにはどうすればよいですか？

開発者向けのFAQをごらんください。

他のDBMSと比べPostgreSQLはどうなのですか？

ソフトウェアを評価する方法にはいくつかあります。機能と性能と信頼性とサポートと価格です。

機能(Features)

PostgreSQLは、トランザクション、サブクエリ、トリガー、ビュー、外部キー整合性参照、および、洗練されたロック機構など、大規模商用 DBMSが持つ機能をほとんど持っています。さらに PostgreSQLは、ユーザ定義型、継承、ルール、そしてロック競合を縮小するマルチバージョン同時性制御など、商用DBMSも持ち合わせないような機能をいくつか持ち合わせています。

性能(Performance)

PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ちます。ある面ではより早かったり、ほかの面ではより遅かったりします。他のデータベースに比べた性能は、ふつう +/-10% くらいでしょう。

信頼性(Reliability)

我々は、DBMSの信頼性が高くなくてはその価値が無いことを理解しています。十分テストして、安定したコードに対してバグを最小にしてからリリースするように努めてます。それぞれのリリースは少なくとも1 カ月以上のベータ・テストを行ない、これまでのリリースの履歴が、製品版として安定した堅固なリリースであることを物語っています。この分野では、他のデータベースと比べても遜色がないことに自信を持っています。

サポート(Support)

我々のメーリングリストは、遭遇するいかなる問題についても解決への手助けをしてくれる、開発者やユーザの大きな集まりへの接点を提供しています。我々は問題の解決を保証することはできませんが、商用データベースであっても常に解決されるわけではありません。開発者や、ユーザ・コミュニティ、マニュアル類、それに、ソースコードなどへ直接アクセスできることによって、PostgreSQLのサポートは、他のDBMS サポートよりも優れたものとなっています。御要望に答えて、事柄毎の商用サポートなどもあります（ FAQ 1.7節をごらんください）。

価格(Price)

PostgreSQLの利用は、商用でもオープンソースでもすべて無料です。上記に示してあるBSDスタイルの使用許諾に外れない限り、PostgreSQLのコードを制限無く商品に取り込むことができます。

PostgreSQLを組み込みに使えますか？

PostgreSQLはクライアント／サーバ・アーキテクチャで設計されていて、クライアントとサーバおよびそれを補助するいろいろなプロセスが別々に走ることが要求されます。多くの組み込みアーキテクチャはこのような要求をサポート可能です。しかし、お使いの組み込みアーキテクチャによっては、データベースサーバがアプリケーション・プロセスの中で実行することを要求される場合があり、Postgresを使うことはできないので、より軽量なデータベースソリューションを選択すべきです。

一般的な組み込み可能なデータベースの選択肢にはSQLiteとFirebird SQLが含まれます。

PostgreSQLのメーリングリストの購読をやめるにはどうすればよいですか？また、電子メールを重複して受け取らないようにするにはどうしますか？

PostgreSQLのMajordomo ページから、PostgreSQLに関する複数のメーリングリストの購読の開始と中止ができるようになっています。（ログインするためにはMajaordomoから送られるパスワードが必要になります。）

PostgreSQLnoすべてのメーリングリストでは、返信はメーリングリストとかつ元のメールの投稿者へ送られるように構成してあります。これにより利用者は、最速でメールへの返信を受けられるようになっています。既に直接受け取っているメールを、リストから重複して受け取りたくない場合は、MajordomoのChange Settingsページから、eliminateccをチェックします。また、selfcopyのチェックをはずすことで、自分の送ったメールのコピーを受け取らないようにもできます。

ユーザ・クライアントの質問

PostgreSQLではどのようなインターフェースが使えますか？

PostgreSQL のインストールに含まれる物はCと組込みCのインターフェースだけです。その他のインターフェースは独立したプロジェクトで、別々にダウンロードされます。別々とすることで、それぞれの開発チームが独自のリリーススケジュールを持つことが許されます。

多くのPostgreSQLインストーラは、PgJDBC、nPgSQL、pg ruby gemモジュール、pycopg2 for Python、DBD::Pg for Perlやその他の言語ごとのクライアントインタフェースを同梱されている、又はダウンロードするように促しています。加えて、いくつかのプログラム言語ランタイムは、プリインストールされたPostgreSQLクライアントライブラリが同梱されています。

Linuxシステムでは、psycopg2のような言語に拘束されるライブラリがパッケージマネージャを利用することで一般的にインストールされます。

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 を使います。

PostgreSQL にグラフィカル・ユーザインターフェースはありますか？

商用とオープンソース開発者によるもの両方で、PostgreSQLには多くのGUIツールが利用可能です。詳細なリストは、 PostgreSQL GUI ツールについてのコミュニティガイド Community Guide to PostgreSQL GUI Toolsにてごらんください。

Many installers bundle the graphical PgAdmin-III client with the installer.

多くのインストーラはグラフィカルなPgAdmin-IIIクライアントがインストーラと共に同梱されています。

   [訳注:
       pgAdmin3 はPostgreSQL標準GUI管理ツールで、Windows版(PostgreSQL
       for Windows) に同梱されています。詳しい情報は、
       http://www.pgadmin.org/ にあります。
   ]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

管理上の質問

ソースコードからインストールする場合に、どのようにすれば /usr/local/pgsql 以外の場所にインストールできますか？

簡単な方法は、 configure を走らせるときに --prefix オプションを指定することです。

Windows又はOS XでPostgreSQLをインストールする場合のpostgresユーザのパスワードがわかりません。

Dave Pageが、別のパスワードが使用されており、それらをリセットするといった一般的な問題の解決方法をblog 投稿しています。

PosgreSQL 9.2では、Windows上でNETWORKSERVICEとして実行されていることからサービスアカウントのパスワードは必要なくなり、postgresデータベースユーザのパスワードのみ所持しています。

他のホストからの接続はどのように制御しますか？

既定値では、PostgreSQL は Unix ドメインソケット、または、TCP/IP接続のローカルマシンからの接続しか許しません。postgresql.conf の中の listen_addresses を修正し、かつ、$PGDATA/pg_hba.conf ファイルを適切に直し、データベースサーバを再起動して、ホストベースの認証を有効にしないかぎりは、他のマシンからは接続できないでしょう。

より良い性能を得るためには、データベース・エンジンをどのように調整しますか

性能改善の可能性のありそうな主な領域が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://old.postgresql.jp/wg/psqltrans/hw_performance_j.pdf) に述べられています。

   [訳注:
     JPUG理事長の片岡裕生氏による、「今すぐできるPostgreSQLチューニング」
     というコーナーが ThinkIT サイトにあり、実作業の参考になります。
       http://www.thinkit.co.jp/free/tech/10/1/1.html
   ]

どのようなデバグ機能が使えますか？

サーバ設定変数には、 http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html に示されるように、多くの log_* があり (JPUGサイトの和訳は http://www.postgresql.jp/document/current/html/runtime-config-logging.html )、クエリとプロセスの統計情報を出力することができて、デバグや性能測定にはとても便利です。

接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？

既定での制限である 100 のデータベースセッションに達してしまっています。

同時接続数の制限を増やす、又はコネクションプーラを増やすためにはNumber of database connectionsを参考にしてください。(JPUGサイトの和訳は http://www.postgresql.jp/document/current/html/runtime-config-connection.html )

PostgreSQLのアップグレードの手順はどうなりますか？

バージョン番号付けの方針について、更新全般についての解説は http://www.postgresql.org/support/versioning を、そして、アップグレードについての一般的な説明は http://www.postgresql.org/docs/current/static/upgrading.html をご覧ください。

[訳注：
  アップグレードについての和訳版は下記にあります。
 http://www.postgresql.jp/document/current/html/upgrading.html
]

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情報を信頼します。

ハードウェアにはどのようなコンピュータを使えばよいですか？

PCハードウェアはほとんど互換性がありますので、ほとんどの人は、すべてのPCハードウェアが同じ品質だと思い込む傾向があります。しかし、それは間違いです。ECC RAM、高品質ハードドライブ／SSD、信頼できる電源、そして高品質マザーボードは、安いハードウェアに比べると、より信頼性が高く、より性能も良いのです。 PostgreSQL はほとんどのハードウェアで稼働しますが、信頼性や性能が重要な場合は、使用中のハードウェアのオプションについて調査することが賢明です。

その他の多くのアプリケーションと異なり、データベースサーバーは、通常 I/Oやメモリーを酷使します。したがって、まずはI/Oサブシステムに焦点を当てることが懸命です。それから、メモリー容量、そして、最終的にCPUの問題を考慮します。高品質な性能の高いSSDの利用は、データベースの性能を上昇させる、往々にしてもっとも安い方法となります。我々のメーリングリスト上でもハードウェアオプションのトレードオフについて議論することができます。

PostgreSQLはCPUのリソースをどのように使いますか？

PostgreSQLサーバはプロセスベース（スレッドではない）で、データベースセッション毎に１つのオペレーティングシステム上のプロセスを使います。データベースセッションは、1つより多くのCPUを利用することはできません。もちろん、複数のセッションでは、オペレーティングシステムによって、自動的に利用可能なCPUのすべてに分けて拡散されます。クライアントアプリケーションでは、簡単にスレッドを使うことができ、それぞれのスレッドから複数のデータベース接続を行うことが可能です。

一つの複雑な、又はCPUに負荷をかけるクエリは、そのクエリを処理するために1つ以上のCPUを使用することが出来ます。OSがディスクI/Oなどで他のCPUをまだ利用できるかもしれませんが、1つの予備CPUコア以上の大きな効果を確認できないでしょう。

何故PostgreQLは待機中にも関わらず、たくさんのプロセスをもっているのですか？

上記にも書かれているように、PosgreSQLはプロセスベースで動作しており、接続ごとに一つのpostgres（又はWindowsではpostgres.exe）インスタンスが起動します。（接続の受入とそのための新たなpostgresインスタンスの起動を行う）postmasterは常時実行しています。加えて、PostgreSQLは通常、状態の収集、バックグラウンド書き込み、autovacuumデーモン、walsenderなどのような一つ以上の"補助的な"プロセスを持っており、それらの全ては多くのシステムモニタツールにて"postgres"インスタンスとして現れます。

多くのプロセスにも関わらず、それらは現実のリソースとしては確かに非常に少量しか使用しません。次の回答を参照してください。

何故PostgreSQLはそんなに多くのメモリを使用するのですか？

何度も出現するにも関わらず、topもしくはWindowsプロセスモニタのようなツールにてPostgreSQLが使用中としている大量のメモリ使用量に到底及びませんが、これはまったくもって通常です。

topもしくはWindowsプロセスモニタのようなツールにて、それぞれが大量のメモリを使用していると考えられる多くのpostgresインスタンス（上記参照）が表示されます。しばしば、合算してみると、postgresインスタンスが利用中のメモリ使用量がコンピュータに実際に実装された何倍ものメモリ容量となります！

これは、これらのツールがどのようにメモリ使用量を報告するかに帰結します。これらのツールは一般的に共有メモリを上手に解釈せず、各々のpostgresインスタンスごとに個別又は排他的に使用されたメモリとして表示されます。PostgreSQLは、バックエンドとキャッシュデータ間の通信の為に、共有メモリの大きなチャンクを使用します。これらのツールが共有メモリブロックを全てのpostgresインスタンスにつき一つをカウントするのではなく、postgresインスタンスにつき一つずつカウントするためとなり、PostgreSQLがどれくらいメモリを使用しているか大きく過大評価します。

更に、これらのツールの多くのバージョンは、個別のインスタンスが起動時に直接使用中の共有メモリ全体を報告せず、むしろ起動してから参照された共有ページの数をカウントします。インスタンスの生存期間を超えて、全てのページを参照するまでますます多くの共有メモリを必然的に参照し、使用量として報告されたそれらの値は共有メモリブロック全体を含めて徐々に増えていきます。これは度々メモリリークとして誤解されますがそのようなことはなく、ただ一つの報告も過去の遺産となっています。

操作上の質問

最初の数行のみを SELECTするにはどうしますか？ランダムな行は？

取得したい行がほんの数行で、SELECT の実行時に取得する行の数が分かっていればLIMIT を使いましょう。インデックスが ORDER BY とマッチすれば、クエリ全体を(丸ごと)実行しなくても済む場合もあります。SELECT する時点で行の数が不明なら、カーソルを使って FETCH しましょう。

ランダムに行をSELECTするには、次の文を使います：

   SELECT col
   FROM tab
   ORDER BY random()
   LIMIT 1;

こちらの、Andrew Gierth氏によるブログエントリご覧になれば、ここでのトピックについてさらに詳しく出ています。

定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか？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 文が沢山あります。

カラムのデータ型を変更するにはどうしますか？

カラムのデータ型の変更は 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をしたほうが良いかもしれません。

行、テーブル、データベースの最大サイズは？

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

   データベースの最大サイズ?        制限無し (32 TB のデータベースも存在します)
   テーブルの最大サイズ?           32 TB
   行の最大サイズ?               400 GB
   フィールドの最大サイズ?          　　1 GB
   テーブル内での最大行数?         制限無し
   テーブル内での最大カラム数?      　カラムの型によって 250-1600
   テーブル内での最大インデックス数?   制限無し

もちろん、これらは実際は無制限ではなく、ディスク容量とメモリーやスワップスペースの大きさにより制限されます。性能はこれらの値がことのほか大きな時に煽りを受けます。

最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファイルのサポートは必要としません。巨大なテーブルは複数の1GBのファイルに分けて保存されますので、ファイルシステムの制限は重要ではありません。

デフォルトのブロックサイズを32kに増加することで、最大テーブルサイズと行サイズと最大カラム数とを4倍にすることができます。また、最大テーブルサイズはテーブルパーティションを使って増やすこともできます。

ひとつの制限は、約2,000文字以上の長さのカラムにインデックスを付けることができないことです。幸いにも、そのようなインデックスは滅多に必要とされません。一意性は、長いカラムのMD5ハッシュの関数インデックスによって最も保証され、また、フルテキストインデックス処理はカラム内の単語を検索することができます。

（それぞれ行のデータ合算値の）サイズが2KBを超える行を含むテーブルを格納する場合、"テーブル内での最大行数"は40億行以下となるので注意してください。詳しくはTOASTを参照してください。

一般的なテキストファイルのデータを保存するには、データベースのディスク容量はどのくらい必要ですか？

普通のテキストファイルを 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型の値は透過的に圧縮されるかもしれないことに注意します。

トピックに関して、こちらのプレゼンテーションもご覧ください：File:How Long Is a String.pdf。

クエリが遅いのはなぜでしょう？なぜ、インデックスが使われないのでしょうか？

インデックスは、すべてのクエリで使われるわけではありません。テーブルが最小サイズより大きく、クエリでそのわずかなパーセンテージのを選択する時だけ、インデックスは使われます。これはインデックススキャンにより起こされるランダムなディスクアクセスは、テーブルをストレートに読むシーケンシャルスキャンよりも遅くなることがあるからです。

インデックスを使うかを決定するために、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 インデックス作成にだけしか役に立たちません。

フルテキスト・インデクシングを単語検索に使うことも可能です。

SlowQueryQuestionsアーティクルに、いくつかのヒントと案内が含まれています。

問い合わせオプティマイザがどのように問い合わせを評価するのかを見るにはどうしますか？

EXPLAINコマンドでこれをするには、Using EXPLAIN を見てください。

テキスト形式の並び替え順を変更するにはどうしますか？

PostgreSQLはテキスト形式データの並び替えを、initdbの際に選択した現行のロケールにより定義されている順番にしたがって行います。 (8.4以降では、データベースを作成するときにロケールを選ぶことができるようになりました。）並び替えが好きでなければ、他のロケールを使う必要があります。得に、"C" 以外のロケールでは、辞書の順番にしたがって並び替えが行われ、句読点や空白は無視されます。もし、そうしたくなければ、 "C" ロケールの必要があります。

正規表現での検索や大文字と小文字とを区別しない正規表現検索はどのように実現しますか？大文字と小文字とを区別しない検索のためのインデックスはどのように使いますか？

~演算子は正規表現照合を行ない、~* は大文字と小文字を区別しない(case-insensitive)正規表現照合を行います。大文字と小文字を区別しない LIKE 演算子を ILIKE といいます。

大文字と小文字を区別しない等値比較は次のように表現できる：

   SELECT *
   FROM tab
   WHERE lower(col) = 'abc';

ここでは、"col"に張られた標準インデックスは使われませんが、もし、"lower(col)"の式インデックスを作成すれば、それが使われます。

   CREATE INDEX tabindex ON tab (lower(col));

上記のインデックスがUNIQUEで作成された場合、カラムは大文字と小文字を格納できますが、その違いが大文字と小文字の違いだけであっても同一にはなりません。あえて特定の文字ケースをカラムに格納するには CHECK制約か、トリガーを使ってください。

PostgreSQL 8.4 以降では、貢献による CITEXT データ型を使うこともでき、内部で"lower()" 呼び出しを実装していますので、まったく大文字小文字を区別しないでそれを効果的に扱うことができます。 CITEXT は8.3用にも利用可能であり、pgFoundryにある初期のバージョンでは、8.2 でもASCII文字のみであれば、大文字小文字を区別しない取扱いができます。

クエリの中で、フィールドが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;

いろいろな文字型のそれぞれの違いは何ですか？

型	内部名	備考
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バイトのみを格納するデータ型のために特別に用意されました。それは、システムカタログに見ることができますが、ユーザテーブルで使用することはお勧めしません。

通番(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億以上の通番が必要と思われる場合には、この型を使います。

シーケンスは、通常の操作の一部において"欠落"または"ギャップ"を含むことがあることに注意してください。1,4,5,6,9,...とキーが作成されてもまったく通常のものとなります。シーケンスギャップのFAQエントリを参照してください。

SERIALデータ型に挿入される値は、どうすれば得られますか？

最も簡単な方法は、割り当てられたSERIAL値を RETURNINGとして取得することです。ひとつ前の例題テーブルを使うと次のようになります。

INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

nextval()を呼び出して、その値をINSERTで使うか、INSERTの後で curval()を呼び出してもかまいません。

currval() によって他のユーザと競合状態に陥ることはないですか？

ありません。currval() は、他のユーザのセッションで起きていることとは独立に、そのユーザのセッションで与えられた最新の連番値を返します。

シーケンス／SERIALカラムへの割り当て番号にギャップがあるのはなぜですか？トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜですか？

同時接続性を改善するために、必要に応じてトランザクションに連番（シーケンス値）を与えています。実行中のトランザクションが終了するまでシーケンスの対象がロックされ続けられないように、他のトランザクションでは他のシーケンスが直ちに割り当てられるようにしています。このため、nextval() 関数の節に記載されているように、トランザクションが中断されたときには割り当て番号に飛び（ギャップ）が発生します。

加えて、クリーンではないサーバのシャットダウンは、PostgreSQLが配布されたシーケンス番号のキャッシュを保持し、クリーンではないサーバのシャットダウンにおいて、その番号が使用されたか確かではないため、リカバリー時にシーケンス値の増加を生じます。シーケンスにおけるギャップ発生のもう一つの原因は、CREATE SEQUENCEにおけるCACHEオプションです。

一般的に、SERIALキーもしくはSEQUENCEにギャップが無いことを信頼、もしくはそれらの順序を予想してはなりません； idがnである時に挿入されたidは、複数のトランザクション内にて使用され、生成された場合にn+1であることが保証されない総合的にキーが等しいことと単純に等しいことを比較してください。

ギャップが無いシーケンスは可能ですが、性能が非常悪くなります。せいぜい一回で一つのトランザクションがギャップのないシーケンスから行を挿入できます。ギャップのないシーケンスに相当する組み込みのSERIALもしくはSEQUENCEは存在しませんが、些細な実装の一つが存在します。ギャップのないシーケンスの実装情報は、Stack Overflowのメーリングリストアーカイブとこの有用なアーティクルにて見つけられます。絶対的なビジネスでの要求があるまで、ギャップの無いシーケンスの仕様は避けてください。動的に生成されるギャップの無い採番を表示に用いる場合は、row_number() ウィンドウ関数もしくは定期的に実行するバッチプロセスを追加することを検討してください。

こちらも参照してください： FAQ: Using sequences in PostgreSQL.

OID とは何ですか？

テーブルがWITH OIDSでつくられた場合は、それぞれの行は、INSERTの際に自動的に詰め込まれる、OIDカラムを含みます。 OIDは順番に割り当てられた4バイトの整数です。最初は、全インストレーションを通して一意な値です。しかし、OIDは約40億で一巡し、その後、OIDは重複します。

OIDカラムに一意の（ユニーク）インデックスを作ることで、一つのテーブル内でのOIDの重複は避けることができます（しかし、WITH OID句ではこれができないことに注意しましょう）。システムはインデックスをチェックし、新たに生成するOIDが既に提供されている場合は、新しいOIDの生成を繰り返します。OIDを含むテーブルがおおよそ40億行を越えないかぎりは、これでうまくゆきます。

PostgreSQLはシステムカタログの中でオブジェクトの識別子にOIDを使いますが、大きさの制限が問題になるのは仕方がありません。

ユーザのテーブルのカラムに一意となるように番号付けをするためには、 OID ではなく SERIAL を、あるいは、テーブルが運用中に20億行を越えることが予想される場合は BIGSERIAL を使うのが最善です。

CTID とは何ですか？

CTID は、テーブル内で、特定の物理行をブロックとオフセットの値で識別するために使われます。 CTIDは、物理行を指し示すためのインデックスの記載に使われます。しかし、時によって、競合する更新が予期されないときは、トランザクションの中で行を識別するためにも役に立ちます。

エラーメッセージ "ERROR: Memory exhausted in AllocSetAlloc()"が出るのはなぜですか？

おそらく、システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能性があります。サーバを始動する前にこれを試してみてください：

   ulimit -d 262144
   limit datasize 256m

シェルによって、どちらかひとつが成功するでしょうが、これはプロセスのデータセグメント制限をより高く設定し、たぶんクエリが完結するようになるでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスについて適用されます。バックエンドがとても多くのデータを返すためにSQL クライアントで問題が続いているのであれば、クライアントを開始する前にこれを試してみてください。

どのバージョンの PostgreSQL を走らせているかを調べるにはどうしますか？

SELECT version(); クエリを走らせます。

データベース操作の監査証跡を残す方法はありますか?

何も組み込まれていませんが、そうした機能を組み立てることがとても難しいわけではありません。

簡単な例は公式文書にもあります： 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

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

CURRENT_TIMESTAMPを使います:

   CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

外部結合(outer join)はどのように実現しますか?

PostgreSQL は SQL 標準構文を使う外部結合(outer join)をサポートします。ここに 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結合と呼ばれます。

複数のデータベースを使う問い合わせはどのようにすればできますか？

現行のデータベース以外へ直接問い合わせする方法はなく、この事項に対する複数のアプローチが存在し、いくつかを以下に記載します。

SQL/MEDをサポートするPostgreSQLでは、リモートデータベースからローカルデータベースにテーブルリンクを作成するための"外部データラッパー"を許可しています。リモートデータベースは同じPostgreSQLインスタンスのもう一つのデータベース、又は世界一周の半分の距離にあるデータベースかもしれませんが、関係ありません。postgres_fdwがPostgreSQL 9.3に組込まれており、読み書きのサポートが含まれています；read-only version for 9.2 がcontribモジュールとしてコンパイル及びインストールされます。

contrib/dblink はデータベース間(cross-database)の問い合わせ関数呼出しを許可し、多くのPostgreSQLの旧バージョンに対応しています。postgres_fdwと違い、リモートサーバに状態を"押し出し"、必要なものより多くの大量のデータを頻繁にフェッチするでしょう。

もちろん、クライアントは同時に接続を別のデータベースへも張らなくてはならず、結果をクライアント側でマージしなくてはなりません。

関数から複数の行またはカラムを返すにはどうしますか？

集合を返す関数(Set Returning Functions): Return more than one row of data from PL/pgSQL functions を使うと簡単です。

PL/PgSQL の関数の中で一時テーブルにアクセスするとき、どうして "relation with OID ##### does not exist" というエラーを受け取るのでしょうか？

バージョン8.3より前の PostgreSQL では、PL/PgSQL は関数スクリプトをキャッシュしたため、運悪くその副作用がありました。PL/PgSQL 関数が一時テーブルにアクセスして後でそのテーブルを消して作りした場合に、関数がもう一度呼び出されたときは、その関数のキャッシュしていた内容がまだ古い一時テーブルを指し示したままだったからです。この、解決策として、PL/PgSQLの中で EXECUTE を一時テーブルへのアクセスのために使います。そうすると、クエリは毎回パースをやり直しされるようになります。

この問題は、 PostgreSQL バージョン8.3 以降では起きません。

どのようなレプリケーションのソリューションがありますか？

「レプリケーション」と一言でいいますが、レプリケーションをするための技術はいくつもあり、それぞれ、利点と欠点があります。このトピックについて、我々の文書のこちらにも良い紹介が含まれています。 http://www.postgresql.jp/document/current/html/high-availability.html

また、レプリケーションソフトウェアとその機能について格子状にまとめたものがReplication, Clustering, and Connection Poolingにあります。

マスタ／スレーブのレプリケーションは、読み／書きのクエリを受け取るシングルマスタが可能で、スレーブでは読み／SELECTの問い合わせだけを受け付けることができます。最も人気がある、フリーで利用できる、マスタ-スレーブのPostgreSQLレプリケーションソリューションは、 Slony-I です。

マルチ-マスタのレプリケーションは、読み／書きのクエリを受けとり、複数のレプリケートさせるコンピュータに送ることができます。この機能は、サーバ間の変更の同期が必要なため、性能に重大な衝撃を与えます。 PGCluster は、このようなソリューションとしてPostgreSQLのためにフリーで利用できるものとして、最も人気があります。

この他にも、商用やハードウェアベースのレプリケーション・ソリューションが利用可能で、いろいろなレプリケーションのモデルをサポートしています。

共有ストレージ型postgresqlサーバクラスタは作成可能ですか？

PostgreSQLは、SAN、SCSIバックプレーン、iSCSIボリューム、又は以外の共有メディア上の共有ストレージを使用したクラスタリングはサポートしていません。このような"RACスタイル"のクラスタリングはサポートされていません。レプリケーションベースのクラスタリングのみが現在サポートされています。

詳細はReplication, Clustering, and Connection Poolingの情報を参照してください。

共有ストレージ 'フェールオーバー'は可能ですが、同時に一つ以上のpostmasterの起動とデータストアへのアクセスは安全ではありません。ハートビート及びSTONITH又はいくつかの他のハードから切断された選択肢が要求されます。

テーブルとカラムの名前がクエリーの中で認識されないのはなぜですか？なぜキャピタライズ(単語先頭の大文字化)は保持されないのですか?

名前が認識されない最も一般的な原因は、テーブルを作成する際に、テーブルやカラムを囲う二重引用符の使用です。二重引用符を使うと、テーブルとカラムの名前（識別子といいます）は大文字と小文字の区別をして格納されます。したがって、pgAdminのようにテーブル作成のときに自動的に二重引用符を使うものはクエリの中でそれらの名前を使うときに二重引用符を付けなくてはならないことを意味します。このため、識別子を認識させるためには以下のいずれかを心がけます。

テーブルを作成するときに二重引用符で識別子を囲うことを避ける
識別子には小文字だけを使う
クエリの中で参照するときは二重引用符で識別子を囲う

データベースのパスワードを忘れてしまいました。取り戻すにはどうしますか？

できません。しかし、設定をやり直したりすることはできます。これをするには、

pg_hba.conf を編集して、一時的に trust 認可を許します
構成ファイルをリロードします (pg_ctl reload)
接続して ALTER ROLE / PASSWORD を新しいパスワードを設定するために発行します
pg_hba.conf を再び編集し、元の設定に戻します
構成ファイルを再びリロードします

PostgreSQLにストアードプロシージャはありますか？

PostgreSQLにストアドプロシージャはありませんが、とても強力な関数を持っていて、ユーザ定義関数の機能をつかって、他のDBMSのストアードルーチン(プロシージャや関数)でできるような大抵の能力は持っていますし、多くの場合はそれ以上のこともできます。

これらの関数は、違う型であっても、いくつかのプログラミング言語で実装することができます。 (詳しくは次の文書を参照ください。ユーザ定義関数)

PostgreSQL の関数はいろいろな方法で呼び出せます。他のRDBMSの中のストアドプロシージャを呼び出すように関数を呼び出したい場合は(一般的に関数は副作用がありますが、その結果については気にしないようにするには、たとえば、戻りをvoid型にすることで)、ひとつのオプションとしては、プロシージャをPL/pgSQL 言語で書いてPERFORM コマンドを使うことです。たとえば、次のとおりです。

注意:

SELECT theNameOfTheFunction(arg1, arg2);

の代わりに、

PERFORM theNameOfTheFunction(arg1, arg2);

とすれば、関数はvoidを返すとしても(この結果はvoid値を含む1レコードとなりますが)、結果は生成されます。

PERFORM は、このように使うことができて無用な結果を破棄することができます。

PostgreSQLのストアドファンクションの主な制限は、真のストアドプロシージャと比べて以下となります：

複数の結果セットを返却できない
自立的なトランザクション(ファンクション内でのBEGIN、COMMITとROLLBACKの使用)をサポートしない
SQL標準のCALL構文をサポートしない（ODBCやJDBCドライバは翻訳するかもしれないが）

何故BEGIN、ROLLBACKとCOMMITはストアドプロシージャ／ファンクションで動作しないのですか？

PostgreSQLは自立的なトランザクションはストアドファンクション内でサポートしていません。すべてのPostgreSQLクエリのように、ストアドファンクションはいつもトランザクション内や制御不可能なトランザクションの外側で実行されます。

トランザクションを制御するストアドプロシージャが必要な場合、dblinkインタフェース、又は代わりにクライアント側のスクリプトの実装を検討することができます。いくつかのケースにて、それぞれのBEGIN/EXCEPTION/ENDブロックで副トランザクションを作成するために、PL/PgSQLにて例外ブロックを使用することができます。

"SELECT count(*) FROM bigtable;"は、なぜ遅いのですか？

9.2以降ではIndex-only scansの恩恵で一般的に遅くありません。

旧バージョンのより多くの情報はSlow Countingを参照してください。

何故プリペアドクエリとして実行した時により遅いのでしょうか？

PostgreSQL 9.2以降においては、一般的あるいは最適化された実行プランの利用が実行単位原則によって決定されるため、この事象はまれです。プランナは悪い選択を行ってしまうかもしれませんので、以下の記述が多少参考になるかもしれません：

PostgreSQLが計画時間として知られているすべてのパラメータを用いてフルクエリを実行している場合、クエリ内で使用される値がカラムの中で高頻度あるいは低頻度に出現するかを見つけるためにテーブル内の統計情報を使用することが出来ます。これは、クエリの特定の部分から大量、又はきわめて少ない結果を予測することを知るものとして、より効率的であるためにデータの取得方法を変更させるものです。例えば、'active=y'の検索を行った場合に、テーブル内のレコードの99%が'active=y'を占めると統計情報がしっており、この場合は連続的検索がより速いであろうことから、索引検索の代わりに連続的検索が選択されるかもしれません。

プリペアドクエリにおいて、PostgreSQLは実行計画の作成時にすべてのパラメータの値を使用しません。プリペアドクエリ実行時にパラメータとして提供される値が何であれ、まずまず良好な結果となる"安全な"実行計画の選択を試行するべきです。ランダムに選択されたテーブル内のいくつかの値の平均よりも、提供された値が運悪く非常に高頻度、又は非常に低頻度である場合は、この実行計画が全く適当ではない場合があります。

もしこの問題があなたを悩ませているようであれば、遅いクエリと早いクエリを比べるためにEXPLAINコマンドの利用を始めてください。EXPLAIN SELECT query...の出力を確認し、実行計画の間に著しい違いがあるか確認するためにPREPARE query... ; EXPLAIN EXECUTE query...の結果を見比べてください。EXPLAIN ANALYZEは行数の予測や件数のような、より多くの情報を提供するかもしれません。

通常、この問題を持つ人たちは、様々な値のパラメータを使って頻繁に実行されるクエリの高価な実行計画のための性能改善オプションとしてというよりは、SQLインジェクションの予防のためのセキュリティ尺度としてプリペアドクエリの使用を試行しています。この人たちはクライアントインタフェース（たとえば PgJDBC）でサポートされているクライアント側のプリペアドステートメントの利用を検討すべきです。PostgreSQLのプロトコルは、サーバ側の持続的なプリペアドステートメントやほとんどのクライアントドライバがサポートしているクライアント側のプリペアドステートメントインタフェースの利用無しにパラメータ化クエリをサポートしています。

現在のところ、PostgreSQLは特定のパラメータ値を利用したプリメアドステートメントの再計画の要求方法を提供していません；しかしながら、9.2以降では、統計情報が望ましい場所を指し示すことをそれなりに自動的に実行できるようになるかもしれません。

Using_EXPLAINを参照してください。メーリングリストで助けを求めるときはGuide to reporting problemsをどうか読んでください。

何故関数内でクエリを実行した時はスタンドアロンで実行した時よりも遅いのでしょうか？

FAQ#何故プリペアドクエリとして実行した時により遅いのでしょうか？を参照してください。PL/PgSQL関数内のクエリはプリペアドとキャッシュされ、あなた自身でPREPAREし、クエリをEXECUTEした時とほぼ同様に実行されます。

もし本当に、テーブルの統計情報の改善、又はクエリの調整は手助けにならないことを問題と考えているなら、クエリの実行ごとに再プリペアするためにPL/PgSQLに強制することができます。これをするためには、PL/PgSQLにて原文の文字列のままのクエリを提供するためにEXECUTE ... USINGステートメントを利用してください。代わりに、quote_literal又はquote_nullableがクエリテキストの置換されたパラメータのエスケープに使用可能です。

文字列のソートが正しくないのは何故ですか？

最初に、使用したいロケールを使用しているか確認してください。データベースに広く適用されているロケールを表示するにはSHOW lc_collateコマンドを利用してください。もしカラムごとの照合を利用している場合はそれらも調べてください。もし全てがあなたの望んだとおりの結果である場合、読み進めてください。

PostgreSQLは文字列ソートにCライブラリのロケール機能を使用しています。そうするともし予想しない文字列の並び順である場合、この問題はCライブラリ内にあります。テキストファイルにsortユーティリティを使用することでCライブラリのソートのアイディアを検証できます。

例：

LC_COLLATE=xx_YY.utf8 sort testfile.txt

もしこの結果がPostgreSQLが提供するものと同一の並び順となる場合、この問題はPostgreSQLの外側に存在します。

PostgreSQLはバイト順序による文字列ソートを行わないという限りにおいて、libcの振る舞いから逸脱しています。これは実際に稀に違いを生じ、通常はユーザがソート順序について不平を言う場合の問題の原因ではく、例えば結合中か事前に結合されたUnicode文字が混在している場合に生じます。

問題がCライブラリにあるとしたら、オペレーティングシステムの担当者と共に取り組まなくてはなりません。しかしながら、Cライブラリのロケール定義に確かなバグが存在すると知られており、それはCライブラリが"正しい"可能性が高く、"正しい"とは承認された国際的もしくは国家規格に沿ってといる意味となりますので注意してください。あるいは、あなたはある言語の順序ルールの複数の同様な正しい解釈の一つと予想します。

よくある不満のパターンは以下が含まれます：

空白文字と特殊文字：ソートアルゴリズムは一般的に複数のパスにて働きます。最初に、全ての文字が照合され、空白と句読点を取り除きます。その後、空白と句読点は照合されません。（これは今後発生する事象を簡易化します）この振る舞いはロケール定義をそれら自身で変更すること（その時ですら困難です）なしに変更することは不可能です。この問題を回避するためにわずかにデータを再構築したいかもしれません。例えば、名前のフィールドをソートする場合、間の空白を無視するために姓と名のフィールドを分けることができます。

大文字／小文字：Cロケール以外のロケールは一般的に大文字と小文字を並び替えます。並び順は与えられたASCIIバイト値に基づく順序の"A B C ... a b c ..."のかわりに"a A b B c C ..."のようになります。これは正しい動作です。

ドイツ語ロケール：？のソート順序はaかaeとして処理されます。これらは共に正常ですが（http://de.wikipedia.org/wiki/Alphabetische_Sortierung を参照）、多くのCライブラリは最初の一つのみ提供します。これを修正するにはカスタムロケールを作成することを要求します。可能ですが、いくつか作業が発生します。

ASCII/byte順番ではない。はい、違います。そんなはずありません。ASCIIはエンコーディングであってソート順番ではありません。もしこれを望むならCロケールを使用することができますが、あなたはASCII以外の文字の能力を駆使してください。

Mac OS X又はBSD系オペレーティングシステムでUTF-8を使用している場合は諦めてください。これらのオぺレーティングシステムのロケール定義は壊れています。

データモデルの質問

どのようにデータを暗号化すればよいですか？

最初に、Bruce Momjian氏のプレゼンテーションのData Protectionという件名を参照してください。（訳注：資料のタイトルは「Data Protection」ではなく「Securing PostgreSQL From External Attack」で、P22以降の「Disk Volume Encryption」が対象箇所となります）出発点として、[GENERAL] Re: Two-way encryptionも参照してください。automatically-encrypted typesのようなものが必要か検討してください。

日本語に関する質問

日本語がうまく扱えないのはなぜですか？

createdb -Eコマンドオプションに UTF8 あるいは EUC_JP のエンコーディングを指定してデータベースを作成するか、次のようにエンコーディングを指定してデータベースを作成してください。

       CREATE DATABASE dbname WITH ENCODING 'UTF8';

もしくは、

       CREATE DATABASE dbname WITH ENCODING 'EUC_JP';

psql でWindowsからアクセスしたときに、日本語が文字化けするのですが？

psqlの中でクライアントのエンコーディングを指定してください。

       SET client_encoding TO 'SJIS'

PostgreSQLデータベースのエンコーディングに使える日本語文字コードは EUC_JP かUTF-8(UNICODE) であるため、Shift-JIS表示のコマンドプロンプトからは、client_encodingを設定しておかないと、日本語を表示する際に文字化けがおきます。

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 にあります。

「日本語版について」

[訳注：
 日本語版の製作については以下の通りです。
 最終更新日:   2016年5月26日
 翻訳者:       桑村 潤 (Jun KUWAMURA <juk at postgresql.jp>)
 このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):

               田仲 稔                石井 達夫               齊藤 知人
               馬場  肇               岡本 一幸               小菅 昭一
               山下 義之              境 真太郎               生越 昌己
               石川 俊行              本田 茂広               せせ じゅん
               神谷 英孝              菅原 敦                 稲葉 香理
               芳賀 靖史              板垣 貴裕               垣谷 学

 をはじめ、ポストグレスに関する話題豊富な日本語PostgreSQLメーリングリスト、
 和訳のきっかけを作ってくれたり、いつもチェックをしてくれたJF(Linux Japanese FAQ)プロジェクト、FreeBSD ドキュメンテーションプロジェクトの方々、
 それから、直接あるいは間接的にかかわってくださるすべてのオープンソースコミュニティのみなさまに感謝いたします。
 （2016年5月、垣谷 学さんが6年間放置されていた翻訳の更新をしてくれました。）

 この翻訳文書は https://wiki.postgresql.org/wiki/FAQ/ja にあります。
 本家WebサイトのFAQ https://www.postgresql.org/docs/faq/ からもたどれます（"PostgreSQL FAQ"　⇒　"日本語"）。　
]