|
|
|
PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ) 原文最終更新日: 20:33, 25 December 2009 一般的な質問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に似たライセンスの下で配布されています。 それは基本的には、利用者がそのコードを好き勝手に利用することが許されています。 制限があるとすれば、このソフトウェアに伴ういかなる問題においても法的に責任を我々に負わせることができないということです。 また、この著作権表示がこのソフトウェアのすべての複製に表示することも必要です。 以下に、我々が使っているライセンス（使用許諾書）を示します： [訳注：
正文は英語です。参考として、訳文を併記掲載します。
]
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' も存在します。
]
1.8) バグレポートはどのように発信しますか？http://www.postgresql.org/support/submitbug のPostgreSQL バグフォームを訪れてください。バグレポートを提出する仕方についての手引と指針があります。 それと同時に ftp サイト ftp://ftp.postgresql.org/pub/ で、最新バージョンのPostgreSQL を探してみてください。 バグフォームを使ったり、あるいはいずれかのPostgreSQLメーリングリストに投稿したりすると、一般的に以下の項目のどれかが返答の内容となります：
1.9) 既知のバグや未だ無い機能はどうやって見つけますか？PostgreSQLは拡張されたSQL:2003のサブセットをサポートします。我々のページの TODOリスト に、既知のバグや欠落機能や将来計画についての記述があります。 特徴の要求は普通次のいずれかの解答の中にあります：
我々は、PostgreSQL に関して、電子メールで直接対応して TODO リストを最新に更新してゆくほうがより効果的であることを知っていますので、バグ追跡システムは使いません。 現実に、このソフトウェアの中でバグはそれほど長くはい続けませんし、多くのユーザに影響するバグは早急に修正されます。 PostgreSQLのリリースで、すべての変更点、改良点、そして、修正点を知りたければ、 CVS のログメッセージを見てください。 リリースノートにさえ、このソフトウェアに加えられたすべての変更点は網羅されていません。 1.10) どのような文書がありますか？配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュアル・ページ)およびいくつかの小さなテスト例題が含まれます。 /docディレクトリをごらんください。 また、マニュアルは、 http://www.postgresql.org/docs/ でオンラインでも閲覧できます。 [訳注:
JPUG 文書・書籍関連分科会で翻訳されたマニュアルもあります。
http://www.postgresql.jp/document/current/
インプレスから、（やや古くなりましたが、）
PostgreSQLオフィシャルマニュアルも出版されています。
]
[訳注:
この本は、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/
にかなりまとめられています。
]
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つあります： クエリの変更クエリを修正してより良い性能を得ることを含みます：
サーバ構成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 あるいは ~ のようなワイルドカード演算子は特別な環境でしか使えません：
フルテキスト・インデクシングを単語検索に使うことも可能です。 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) いろいろな文字型のそれぞれの違いは何ですか？
内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。 上記の型のうち最初の４つの型は "varlena" 型です(すなわち、フィールド長が明示的にディスクに保存され、それの後に実際のデータが続きます)。このように実際の空間は期待された大きさよりも少し大きくなります。しかし、長い値は圧縮されるので、ディスク上の空間は思ったよりも小さくなります。
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 以降は自動的には行なわれなくなりました。
]
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)データベースのパスワードを忘れてしまいました。取り戻すにはどうしますか？できません。しかし、設定をやり直したりすることはできます。これをするには、
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 <juk at postgresql.jp>)
この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」（翻訳者ページ）
]
|
[ |