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

    [訳注:
	  1999年7月23日、日本PostgreSQLユーザー会(にほん ぽすとぐれす ゆーざー かい)、略称JPUG
	が設立されました。JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。  
	2003年5月17日の総会を以って、「日本PostgreSQLユーザ会」に名称を改めました。
	正会員の会費は無料ですが、協賛会員の会費と会員の積極的な貢献が会の運営を助けています。
	詳しくは、JPUG のWeb サイト:
		http://www.PostgreSQL.jp/
	をご覧ください。会員登録も可能となっています。
	  1990年代中ごろより、ポストグレスの日本語メーリング・リストを石井 達夫さんが主催しています。詳細は、
		http://www.sra.co.jp/people/t-ishii/PostgreSQL/ML/info.html
	をご覧下さい。アーカイブを、いわきりさんのpgsql-jp ML検索システム
		http://datula.mio.org/~iwakiri/pgsql_jp/
	で検索することもできます。
	]

商用サポート会社のリストはhttp://www.ca.PostgreSQL.org/users-lounge/commercial-support.htmlにあります。

    [訳注:
	 日本では、SRA Inc. オープンシステム事業部 にて商用サポートが行なわれています。
	ミラクル・リナックス株式会社 で "Miracle Linux for PostgreSQL" の販売とサポートが
	開始されました。
    ]

1.7) 最新版はどれですか

PostgreSQL の最新版はバージョン 7.3.2 です。

我々は、4カ月毎にメジャーリリースを行なうことを計画しています。

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

配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュアル・ページ)およびいくつかの小さなテスト例題が含まれます。/doc ディレクトリをご覧下さい。また、マニュアルは、http://www.ca.PostgreSQL.org/docs/でオンラインでも閲覧できます。

    [訳注:
	（株）SRAと日本PostgreSQLユーザ会で翻訳され、
	「PostgreSQL オフィシャルマニュアル」
	として出版されています。
    ]

オンラインで参照できる PostgreSQL の本も2冊あります。http://www.PostgreSQL.org/docs/awbook.html

    [訳注:
	日本ポストグレスユーザー会の	「PostgreSQL Book翻訳分科会」
	にて翻訳されました。
    ]

[訳注: 和訳文書は、日本ポストグレスユーザー会のhttp://www.postgresql.jp/document/ をごらん下さい。 ]

psql も、型、演算子、関数、集約、その他の情報をお見せする、いくつかの素晴らしい \d コマンドを持ちます。

我々の Web サイトには、もっと沢山の文書があります。

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

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

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

http://www.PostgreSQL.org/docs/awbook.html にあるPostgreSQL本で SQL を教えています。

    [訳注:
	日本ポストグレスユーザー会の	「PostgreSQL Book翻訳分科会」
	にて翻訳され出版されています。
    ]

その他にも PostgreSQL本として、http://www.commandprompt.com/ppbook があります。 素晴らしい手引書は、http://www.intermedia.net/support/sql/sqltut.shtm, http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, そして、http://sqlcourse.com にあります。

その他では、 "Teach Yourself SQL in 21 Days, Second Edition" が http://members.tripod.com/er4ebus/sql/index.htmにあります。

多くのユーザに、 The Practical SQL Handbook, Bowman Judith S. et al., Addison-Wesley が好評です。 その他に、The Complete Reference SQL, Groff et al., McGraw-Hill のようなのもあります。

    [訳注:
	 石井達夫氏による日本語の参考文献の紹介ページ
		http://www.SRA.co.jp/people/t-ishii/PostgreSQL/doc-jp/index.html
	があります。
	 近藤直文氏の「初心者向のＤＢ設計入門・ＳＱＬ入門参考書紹介」のコーナー
		http://www.shonan.ne.jp/~nkon/ipsql/books_SQL.html
	があります。
	 堀田倫英氏の「PostgreSQL日本語マニュアル」
		http://www.net-newbie.com/
	ではオンラインマニュアルの検索ができます。
	 丸山不二夫氏のUNIX データベース入門
		http://www.wakhok.ac.jp/DB/DB.html
	もオンラインで読むことができます。
    ]

1.11) PostgreSQLは西暦2000年問題(Y2K)に対応していますか？

対応してます。西暦2000年より後の日付も、紀元前2000年より前の日付も、簡単に扱えます。

1.12) 開発チームにはどのように参加しますか？

まず最初(１番目)に、最新のソースをダウンロードし、我々の Web サイトか配布に含まれているPostgreSQL Developersの文書を読みます。 ２番目に、pgsql-hackers と pgsql-patches メーリング・リストを購読(subscribe)します。 ３番目に、高品質のパッチをpgsql-patchesに発信します。

およそ十人ちょっとの人達が、PostgreSQL CVSアーカイブにコミットする権限を持っています。 そのそれぞれの人達が沢山の高品質なパッチを発信するので、現在コミッターとなっている人達はそれに追い付くのが大変ですが、我々は彼らがコミットしたパッチは高品質であると確信しています。

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

http://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (バグツール)のページを訪れてみて下さい。 バグレポートを提出する仕方についての手引と指針があります。

その前に http://PostgreSQL.orgにある最新の FAQ をチェックして下さい。

それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/で、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。

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

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

機能(Features)

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

性能(Performance)

PostgreSQLは他の商用あるいはオープンソースのデータベースと互角の性能も持ちます。ある面ではより早かったり、ほかの面ではより遅かったりします。MySQLなどの特化型データベース・システムにくらべて、PostgreSQLの挿入／更新が遅いのは、トランザクションによるオーバーヘッドがあるからです。もちろん、MySQLには上記のFeaturesの節に示すような機能はまったくありません。我々は、PostgreSQLに柔軟性と機能性を組み込みながらも、絶えず、プロファイラーに掛けたりソースコードを解析したりして、性能の改善を続けています。PostgreSQL と MySQL とを比較している面白い Web ページがhttp://openacs.org/philosophy/why-not-mysql.htmlにあります。
PostgreSQLは、Unixプロセスを起動することによりユーザー接続を操作します。複数のバックエンド・プロセスが情報をロックしながらデータ・バッファーを共有します。マルチCPUでは、簡単に複数のバックエンドをそれぞれのCPUで走らせることができます。

信頼性(Reliability)

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

サポート(Support)

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

価格(Price)

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

1.15) PostgreSQLを資金面で援助するにはどうすればよいですか？

PostgreSQLは、我々が始めた 1996年以来、最高クラスの情報基盤を持っています。これはすべて、Marc Fournieさんのおかげで、彼はこの基盤を何年にもわたって創造し管理してきました。

質の良い基盤はオープンソース・プロジェクトにとってはとても大切なもので、前進する勢いを失うプロジェクトの分裂を回避します。

もちろん、この基盤は安いものではありません。維持し続けるためには毎月あるいは一時の経費がかかります。もし、あなたやあなたの会社に、こうした努力のための資金を助けるために施すことができるようでしたら、https://store.pgsql.com/shopping/から寄付をお願いします。

また、Webページには PostgreSQL,Inc とありますが、そこの"義援(contributions)"アイテムは PostgreSQL プロジェクトをサポートするためだけのためで、決して特定の会社のための資金のためではありません。もし、手形(check)の方が都合がよければ連絡先の住所へお送り下さい。

さらに、もし、PostgreSQLでの成功例をお持ちであれば、ぜひ、われわれの事例サイト http://advocacy.postgresql.orgへお送りください。

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

2.1) PostgreSQL のための ODBC ドライバーはありますか？

PsqlODBC と OpenLink ODBC の二つの ODBC ドライバーが利用可能です。

PsqlODBC は次の場所からダウンロードできます。 http://gborg.postgresql.org/project/psqlodbc/projdisplay.php

    [訳注:
	最新版は井上博司さんのサイトにあります。
	●http://w2422.nsk.ne.jp/~inoue/indexj.html
    ]

OpenLink ODBC は http://www.openlinksw.com/から入手できます。標準的な ODBC クライアント・ソフトウェアで使えますので、支援しているすべてのプラットホーム(Win, Mac, Unix, VMS)から PostgreSQL の ODBC が利用できます。

たぶん彼らは、商用品質のサポートの必要な人々に売っていると思いますが、 フリーウェア版はいつでも入手可能のようです。質問は、postgres95@openlink.co.uk へ送って下さい。

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

    [訳注:
	WDB は、Web から DataBase への Perl の Interface です。
	wdb-p95 へのリンクは切れてしまっています。おそらく、Perl DBI 経由で DBD::Pg の利用が可能と思われます。
	現在、WDBI という名前になっているもの
		http://www.egroups.com/list/wdb-users/
	と、WDBの名前のままのもの
		http://www.i-con.dk/wdb/
	とがあります。その経緯はよくわかりません。
    ]

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

もちろん、PostgreSQL へのグラフィカルインターフェイスがいくつかあります。 その中にPgAccess http://www.pgaccess.com も含まれます。 PgAdmin II (http://www.pgadmin.org Win32-only)もあります。 RHDB Admin (http://sources.redhat.com/rhdb/ )と Rekall ( http://www.thekompany.com/products/rekall/, proprietary)もありま す。 PHPPgAdmin ( http://phppgadmin.sourceforge.net/ ) はPostgreSQLへのWebベースの インターフェイスを提供します。

PgAccess と呼ばれる素晴らしいグラフィカル・ユーザ・インターフェイスがあり、この配布と共に出荷されます。PgAccess にはレポート・ジェネレータもあります。Web ページはhttp://www.pgaccess.org/です。

より詳細なリストについては、http://techdocs.postgresql.org/guides/GUITools をご覧ください。

2.4) どのような言語で PostgreSQL と通信できすか？

人気のあるほとんどの言語はPostgreSQLへのインターフェイスを持っています。 あなたが使うプログラミング言語の拡張モジュールのリストを覗いてみてください。

以下のインターフェイスはPostgreSQLの配布に含まれています。

• C (libpq, libpgeasy)
• 埋め込みC (ecpg)
• Java (jdbc)
• Python (PyGreSQL)
• TCL (libpgtcl)

その他の利用可能なインターフェイスは http://www.PostgreSQL.org/interfaces.html および、 http://gborg.postgresql.org のDrivers/Interfacesのセクションにあります。

    [訳注：
	永安悟史さんは Palm 版の libpq を開発されました。
		http://www.snaga.org/libpq/
    ]

管理上の質問

3.1) どのようにすれば /usr/local/pgsql 以外の場所にインストールできますか？

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

3.2) postmaster を走らせると、Bad System Call とかコア・ダンプしたとのメッセージが出ます。なぜですか？

さまざまな問題が考えられますが、まず最初にあなたのカーネルに System V IPC の拡張がインストールされているかを確認して見てください。PostgreSQL はカーネルによる共有メモリーとセマフォのサポートを必要とします。

3.3) postmaster を走らせようとすると、IpcMemoryCreate エラーが出ます。なぜですか？

カーネルが共有メモリーを持つ設定になっていなかったか、でなければ、カーネルに対して使える共有メモリーの大きさを大きく設定する必要があります。具体的な大きさは、使っているアーキテクチャとpostmaster を走らせるときに設定するバッファの数とバックエンドプロセスに依存します。ほとんどのシステムでは、既定値のバッファサイズのままで、少なくとも約1MBが必要です。 PostgreSQL Administrator's Gideに共有メモリーとセマフォについての情報の詳細がありますのでご覧ください。

3.4) postmasterを走らせようとすると、IpcSemaphoreCreate エラーが出ます。なぜですか？

もしエラーメッセージがIpcSemaphoreCreate: semget failed (No space left on device)であれば、カーネルが十分なセマフォを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォを必要とします。とりあえずの解決策はpostmasterを起動するときに、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを-Nで使います。より恒久的な解決策は、カーネルのSEMMNS と SEMMNI パラメータを増やすことです。

操作不能のセマフォも過度なデータベースアクセスの間にクラッシュを 起こす可能性があります。

もし、エラーメッセージがなにか他のものであれば、カーネルの構成でまったくセマフォのサポートをしていないかもしれません。 PostgreSQL Administrator's Gide に共有メモリーとセマフォについての情報の詳細があります。

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

既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postmaster 起動に -i フラッグを加え、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。

操作不能なセマフォも過度のデータベースアクセス中にクラッシュを引き起こすことがあります。

3.6) より良い性能を得るためには、データベース・エンジンをどのように調整すれば良いですか？

確かにインデックスは問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どのインデックスが使われているかを見ることができます。

もし INSERT を多用している場合は、COPY コマンドを使って大きなバッチ処理でそれを行なうことを検討して下さい。これは、INSERT を別々に行なうよりもっと高速です。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中に無い文は、それら自身がそれぞれのトランザクションに入っていると見なされます。いくつかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが減ります。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。

チューニングのオプションがいくつかあります。postmaster を -o -F オプションで起動することによって、fsync() を無効にすることができます。これによって、各トランザクション毎に fsync() でディスクを更新するのを止めさせます。

postmaster -B オプションを使ってバックエンド・プロセスにより使われる共有メモリー・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、カーネルの共有メモリー空間の制限値を越えてしまっうために postmaster が走らなくなるでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64 です。

バックエンドを -S オプションを使って、それぞれのバックエンド・プロセスが一時的な並べ替えによって使うメモリーの最大サイズを増やすこともできます。 その -S の値はキロバイト単位で、既定値は 512 (すなわち、512K)です。

また、CLUSTER コマンドを使って、テーブルのデータをインデックスに合わせるためにグループ化することもできます。詳しくは、オンラインマニュアルで CLUSTER を見て下さい。

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

PostgreSQL は、デバグのために意味のある、状態情報を報告するいくつかの機能を持ちます。

まず、--enable-cassert オプションで configure を走らせます。そうしてコンパイルすることにより、沢山の assert() が、バックエンドの進捗状況を監視し、何か予期せぬことが起きるとプログラムを停止するようになります。

postmaster と postgres の両方でいくつかのデバグ・オプションの利用ができます。まず、次のように postmaster を起動するときはいつでも、標準出力とエラー出力をログ・ファイルに送るようにしてあることを確かめて下さい。

	cd /usr/local/pgsql
	./bin/postmaster >server.log 2>&1 &

これにより PostgreSQL の最上部のディレクトリに server.log ファイルが置かれます。このファイルはサーバーが遭遇した問題やエラーについて有用な情報を含みます。Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オプションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファイルを生成することに注意しなくてはなりません。

もし、postmasterが走っていなければ、postgresバックエンドをコマンド行から走らせることができ、直接SQL文をタイプすることができます。このやりかたは、デバグ目的のときだけお奨めします。セミコロンではなく、改行が問い合わせの終りになることに注意してください。もし、デバグシンボルを入れてコンパイルしていれば、デバッガを使って何が起きているかを見ることができます。postmaster からバックエンドを開始したわけではないので、独立な環境で走っているのではなくロック／バックエンドとの対話の問題が重複することはありません。

もし、postmasterが走っていれば、あるウィンドウで psqlを開始すると、psql で使われる postgres プロセス のPIDが見つかります。デバッガを使って postgresのPIDにアタッチ(attach)します。デバッ ガの中からブレーク・ポイントをセットし、psql から問い合わせを発行 します。デバグのためにpostgresを始動する場合は、PGOPTIONS="-W n" を設定でき、それから、psql を開始します。これにより、n 秒 開始を遅らせるはずなので、デバッガでプロセスにアタッチして、ブレークポイ ントを設定し、開始から順を追って見てゆくことができます。

PostgreSQL プログラムには、デバグと性能測定にとても役に立つ -sや -Aや -t 等のオプションがあります。

何という関数がどのくらい実行時間を食っているかを見るために、プロファイリング（プロフィール付き）でコンパイルすることも可能です。そのバックエンドのプロフィール・ファイルは pgsql/data/base/dbname ディレクトリに格納されるでしょう。クライアントのプロフィールはクライアントの現行ディレクトリに置かれるでしょう。Linux でまともなプロファイリングを行うには -DLINUX_PROFILE でコンパイルする必要があります。

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

postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があります。

既定の最大プロセスは32プロセスです。-Nに適切な値を引数にしてpostmasterを再起動するか、PostgreSQL.conf を修正することによって、その値を増やすことができます。 。既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。

もし、-N を 32よりも大きくするのであれば、-Bも既定の64より大きい値に増加させなくてはならないし、-B は少なくとも -N の2倍はなくてはならず、おそらく最高性能を望むならばそれより大きい値が必要なはずです。バックエンドプロセスをたくさんにすると、いろいろなUnixカーネル構成パラメータも増やすことが必要になるかもしれません。 共有メモリー・ブロックの最大値(SHMMAX)、 セマフォの最大数(SEMMNSとSEMMNI)、 プロセスの最大数(NPROC)、 ユーザ毎の最大プロセス数(MAXUPRC)、 開くファイルの最大数(NFILEとNINODE も確認事項に含まれます。 PostgreSQLに許されるバックエンドのプロセス数が制限されているのは、 システムのリソースを使い果してしまうことを避けるためです。

3.9) pgsql_tmp ディレクトリの中には何がありますか？

問い合わせ実行モジュールによって生成された一時的なファイルが、このディ レクトリに含まれます。例えば、もし ORDER BY 句を満たすためにバックエンドの -S パラメータで許可した値よりも大きなスペースがソートの際に必要だとすると、溢れたデータを保持するために一時的なファイルがいくつかここに生成されます。

一時的なファイルは自動的に消し去られるはずですが、もし、ソートの途中でバックエンドがクラッシュしてしまうとそうはなりません。postmasterの停止とリスタートでこれらのファイルはディレクトリから消しさられます。

    [訳注：
	 SYSLOGD 経由でログを出力するには、まず、configure を --enable-syslog 
	付きで走らせた後、コンパイルとインストールを行ないます。
	 次に、syslog.conf に local?.* の 出力先を指定し(環境変数で変更可能)、
	syslogd に HUP シグナルを送って初期化しておきます。そして、
	$PGDATA/pg_options に syslog=2 を加えて、 postmaster を -S 
	オプション付きにてサーバモードで起動します。(バージョン 7.1 からは 
	pg_options は PostgreSQL.conf になっています。)
    ]

3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしなくてはならないのはなぜですか？

PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から 7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような)では、システムテーブルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出力し、それを新しい内部フォーマットに読み込むことができます。

同一リリースではディスク上でのフォーマットに変更はないので、アップグレードにはダンプ／リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノートには、pg_upgrade が利用可能なリリースかどうか記されています。

操作上の質問

4.1) バイナリ・カーソルと通常カーソルとの厳密な違いは何ですか？

詳述は、オンラインマニュアルで DECLARE を見て下さい。

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

オンラインマニュアルでFETCHを見てください。あるいは、SELECT ... LIMIT....を使ってみて下さい。

たとえ、欲しいのは最初の数ロウだけでも、すべての問い合わせを評価しなくてはならないかもしれません。ORDER BY を持った問い合わせを使うことを考えてみて下さい。 もし、ORDER BYに合ったインデックスがあるとすると PostgreSQLは要求された最初の数ロウだけで評価できるかもしれませんが、でなれば、PostgreSQL は意図したロウが生成されるまですべてのロウを評価しなければならないかもしれません。

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

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

4.3) テーブルやその他の情報のリストを psql で見るにはどうしますか？

psqlのソースコードとして書かれた pgsql/src/bin/psql/describe.c ファイルを読むことがその答えです。 そこには、psqlのバックスラッシュコマンドによる出力のためのSQLコマンドが含まれています。 psql に -E オプションをつけて起動すれば、与えたコマンドを実行するための問い合わせが出力されます。

4.4) テーブルからカラムの削除、あるいは、データ型を変更するにはどうしますか？

DROP COLUMN機能が、ALTER TABLE DROP COLUMN としてリリース7.3 に加えられました。それまでのバージョンでは、その代わりにこうします:

	BEGIN;
	LOCK TABLE old_table;
	SELECT ...  -- 削除したいカラム以外のカラムをすべて選択します。
	INTO TABLE new_table
	FROM old_table;
	DROP TABLE old_table;
	ALTER TABLE new_table RENAME TO old_table;
	COMMIT;

カラムのデータタイプは次の文で変えられます：

    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 DROP COLUMN old_col;
    COMMIT;

これを行なったときは、抹消された行が使っているディスク空間を回収するためにVACUUM FULL tabをしたほうが良いかもしれません。

4.5) ロウ、テーブル、データベースの最大サイズは？

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

データベースの最大サイズ? 	制限無し (4 TB のデータベースも存在します)
テーブルの最大サイズ?           16TB
ロウの最大サイズ?               1.6TB
フィールドの最大サイズ?         1GB
テーブル内での最大ロウ数?       制限無し
テーブル内での最大カラム数?     カラムの型により250-1600
テーブル内での最大インデクス数? 制限無し

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

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

デフォルトのブロックサイズを32kにすると最大テーブルサイズと最大カラム数とが増加します。

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

例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを考え てみましょう。テキストの文字列の平均長さを20バイトと仮定すると、フラット ファイルの大きさは約2.8MB です。このデータを含む PostgreSQL データベース ファイルの大きさは次のように約6.4MBと見積もることができます：

    36 bytes: 各ロウのヘッダ(概算)
    24 bytes: 整数(int)フィールドとテキスト(text)フィールド
   + 4 bytes: ページ上のタップルへのポインタ
   ----------------------------------------
   64 bytes per row

   PostgreSQL のデータページサイズは 8192バイト(8KB)なので:

   8192 bytes per page
   -------------------   =  128 rows per database page (切り上げ)
     64 bytes per row

   100000 data rows
   --------------------  =  782 database pages
      128 rows per page
 
782 database pages * 8192 bytes per page  =  6,406,144 bytes (6.4 MB)

インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされるデータを含む以上、それなりに大きくなります。

NULLはビットマップに保存されていて、それらがわずかにスペースを使います。

4.7) 定義されたテーブル、インデックス、データベース、および、ユーザをどのようにして見つけ出しますか？

psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。

また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。また、pg_ で始まるシステムテーブルにも記述されています。さらに、psql -l はすべてのデータベースをリスト表示します。

4.8) 問い合わせが遅いうえ、インデックスを使っている様子がありません。なぜですか？

インデックスを使うかを決定するために、PostgreSQL はテーブルについ ての統計情報を持たなければなりません。この統計情報は、VACUUM ANALYZEまたは、単に ANALYZE を使って収集すること ができます。統計情報を使ってオブティマイザはテーブルの中にあるロウ数を知 り、インデックスを使うべきかのの決定をより正しくできます。統計情報は最適 な結合順や結合方法を決める上でも貴重なものもあります。統計情報の収集は、 テーブルの内容がかわると毎に繰返しなされるべきです。

インデックスは、通常 ORDER BY や結合を行な うためには使われません。順次スキャンに続く明示的ソートは、巨大なテーブル のインデックススキャンよりも普通は高速です。

    SELECT col
    FROM tab
    ORDER BY col [ DESC ]
    LIMIT 1;

もし、オプティマイザが間違ってシーケンシャルスキャンを選択したことに疑いがなければ、SET enable_seqscan TO 'off'を使ってインデクススキャンでまちがいなく速くなっているかをテストをしてみてください。

LIKE あるいは ~ のようなワイルドカード演算 子は特別な環境でしか使えません：

• 検索文字列が文字列の最初にききます。たとえば：
• LIKE パターンが%で始まらない
• ~ (正規表現) パターンは^で始まらなければならない
• 検索文字列を文字クラスから始めることはできません。たとえば、[a-e]。
• ILIKE や ~* のような大文字と小文字を区別し ない検索は使えません。そのかわり、このFAQの4.12節で説明する関数のインデックスが使えます。
• initdb においては、デフォルトでCロケールが使われなくてはなりません。

[訳注： 強制的にインデックスを使うには SET enable_seqscan = off を実行します。 ]

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

オンラインマニュアルで EXPLAIN を見て下さい。

4.10) R-tree インデックスとは何ですか？

R-tree インデックスは空間的なデータにインデックスを付けるために使われます。ハッシュインデックスでは範囲の検索ができません。また、B-tree インデックスでは、１次元でしか範囲の検索ができません。R-tree インデックスであれば多次元のデータを扱えます。たとえば、もし R-tree インデックスを point 型の属性に付けることができるとするとシステムは、「長方形に囲まれた点をすべて選択する」というような問い合わせに、より効率良く答えられます。

R-Tree の設計の原典となる権威ある論文は:

Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.

この論文は、Stonebraker 教授の "Readings in Database Systems" でも取り上げられています。

    [訳注：
	  奈良先端大の石川佳治さんよりR-Tree関係の文献を紹介して頂きました。
	日本語 Postgres ML のアーカイブから "Subject: [postgres95 801] spatial data structures" 
		http://www.sra.co.jp/people/t-ishii/PostgreSQL/mhonarc/pgsql-jp/1996Oct/msg00007.html
	をご覧下さい。
    ]

組込みの R-Tree でポリゴンやボックスを操作できます。理論的にはR-Tree はもっと高い次元を操作するようにも拡張できます。実質的には、R-Tree の拡張にはちょっとした作業が必要でして、現在、我々はそれをどのようにするかについての文書を持っていません。

    [訳注：
	  インターウィズの片岡さんが多次元幾何オブジェクトへの拡張作業中です。詳しくは、
	http://www.interwiz.koganei.tokyo.jp/software/geometric/index.html
	をご覧ください。
    ]

4.11) 遺伝的問い合わせ最適化とは何ですか？

GEQO モジュールは、沢山のテーブルを結合するときに、遺伝的アルゴリズム(GA)で問合わせを高速化します。これにより、しらみつぶしに探索を行なわなくても、大きな結合(join queries)を扱うことができるようになります。

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

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

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

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

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

	WHERE lower(textfield) LIKE lower(pattern)

4.13) 問い合わせの中で、フィールドが NULL であることを検出するにはどうしますか？

カラムを IS NULL と IS NOT NULL とで試してみます。

4.14) 様々な文字型のそれぞれの違いは何ですか？

Type            Internal Name   Notes
--------------------------------------------------
CHAR(n)         bpchar          指定された固定長となるように空白が詰められる
"char"          char            １文字
VARCHAR(n)      varchar         最大長のサイズを指定する、詰め物無し
TEXT            text            長さに上限の無いテキスト
BYTEA           bytea           可変長のバイト配列(null-byte safe)

内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。

上記の型のうち最初の４つの型は "varlena" 型です(すなわち、ディスクの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数ロウに渡って保存されたりして、ディスク上の空間は思ったより小さくなります。

VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存ためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性ををもちます。

4.15.1) 通番(serial)／自動増分フィールドはどのようにつくりますか？

PostgreSQL は SERIAL データ型をサポートします。カラム上に通番とインデックスを自動作成します。たとえば、

	CREATE TABLE person ( 
		id   SERIAL, 
		name TEXT 
	);

	CREATE SEQUENCE person_id_seq;
	CREATE TABLE person ( 
		id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
		name TEXT 
	);
	CREATE UNIQUE INDEX person_id_key ON person ( id );

    [訳注：
	CREATE UNIQUE INDEX person_id_key ON person ( id );
	は、 7.3 からは自動的には行なわれなくなりました。
    ]

また、各ロウのOIDフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてりロードする必要がある場合は、OIDを温存するためにpg_dump で -oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があります。 Bruce Momjian の(http://www.PostgreSQL.org/docs/aw_pgsql_book)の Numbering Rowsの章にありあます。

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

ひとつの方法は、nextval() 関数を使ってその値を挿入する前(before)に SEQUENCE オブジェクトから次の SERIAL 値を取り出し、それから実際に挿入をすることです。4.15.1 のテーブルの例を使うとすると、疑似言語ではこのようになります。

	new_id = execute("SELECT nextval('person_id_seq')");
	execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

あるいは、与えられたSERIAL値を、それが既定値として挿入された後で(after)、 currval() 関数を使って取り出すこともできます。たとえば、

	execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
	new_id = execute("SELECT currval('person_id_seq')");

4.15.3) 他のユーザとの競合状態を避けるためには、currval() と nextval() は使わないほうがよいのでしょうか？

それはありません。currval() は、すべてのユーザではありませんが、あなたのバックエンドに与えられた現在の値を返します。

4.15.4) トランザクションが中断したときにもういちどシーケンス番号が使われないのはなぜですか？シーケンス／SERIALカラムに空きがあるのはなぜですか？

同時性を改善するために、実行中のトランザクションに、必要でトランザクションが終了するまでロックされないシーケンス値を与えています。このためトランザクションが中断されると番号割り当てにギャップを生じます。

4.16) OID とは何ですか？ TID とは何ですか？

OID とは一意のロウID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべてのロウは一意の OID を得ます。initdb で発生される OID はすべて 16384 (include/access/transam.h から)より小さな値です。initdb 後のすべての OID (ユーザ作成)はそれ以上の値になります。 既定では、これらすべての OIDは一つのデーブルやデータベース内に留まらず、PostgreSQL インストレーション全体の中で一意です。

PostgreSQL はテーブル間のロウを結びつけるために、そのシステムテーブル内に OID を使います。この OID は特定のユーザのロウを識別するためや結合の中で使われることができます。OID の値を保存するためには OID 型をカラムに使うことを奨めます。より速くアクセスするために OID フィールドにインデックスを作ることができます。 OID は、全てのデータベースで使われる中央領域から、全ての新しいロウに割り当てられます。OID を他の何かに変えたい、あるいは元の OID もテーブルと一緒にコピーしたいのなら、できなくはありません。

        CREATE TABLE new (old_oid oid, mycol int);
        SELECT old_oid, mycol INTO new FROM old;
        COPY new TO '/tmp/pgtable';
        DELETE FROM new;
        COPY new WITH OIDS FROM '/tmp/pgtable';

OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。

TID は特定の物理ロウをそのブロックとオフセット値で識別するために使われます。TID はロウが修正されたり再ロードされると変わります。それらの TID は、物理ロウを指すためにインデックス記載で使われます。

4.17) PostgreSQL で使われるいくつかの用語の意味は何ですか？

いくつかのソースコードや古い文書の中には、それぞの専門分野の中でもっと一般的に使われる専門用語が使われています。

• テーブル(table)、関係(relation)、クラス(class)
• ロウ(row)、レコード(record)、タップル(tuple)
• カラム(column)、フィールド(field)、属性(attribute)
• 取得(retrieve)、選択(select)
• 置換(replace)、更新(update)
• 追加(append)、挿入(insert)
• OID, 連番(serial value)
• ポータル(portal), カーソル(cursor)
• 領域変数(range variable)、テーブル名(table name)、テーブル別名(table alias)

一般的なデータベース用語のリストは：http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html で見つけられます。

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

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

	ulimit -d 262144
	limit datasize 256m

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

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

psql から SELECT version(); をタイプします。

4.20) ラージ・オブジェクトの操作でinvalid large obj descriptor を受け取りました。なぜでしょうか？

ラージ・オブジェクト操作をするときは、前後にBEGIN WORKとCOMMITを付ける必要があります。すなわち、lo_open ... lo_closeをはさみ込みます。

現在は、PostgreSQLのトランザクションのコミット時にラージ・オブジェクト・ハンドルを閉じることにより、lo_openコマンドが完了した直後に強制的にルールを実行します。このため、最初にハンドルに対して何かをしようとすると、invalid large obj descriptor(ラージ・オブジェクトの記述子が不正)となります。それで、もし、トランザクションを使うのを忘れると、（少なくともほとんどの時間）働いていたコードがエラーメッセージを出すのです。

もし、ODBCのようなクライアントインターフェイスをお使いなら、auto-commit offを設定する必要があるかもしれません。

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

CURRENT_TIMESTAMPを使います:

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

4.22) なぜ、INを使う副問い合わせがとても遅いのですか？

現在、外部問い合わせの各ロウについて副問い合わせの結果を順番にスキャンすることにより、副問い合わせを外部問い合わせに結合しています。もし、副問い合わせが数行しか返さず、外部問い合わせが沢山の行を返すなら、当面はINをEXISTSで置き換えることです：

	SELECT *
	FROM tab
	WHERE col1 IN (SELECT subcol FROM subtab)

	SELECT *
	FROM tab
	WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col)

4.23) 外部結合(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);

	SELECT tab1.col1, tab2.col2
	FROM tab1, tab2
	WHERE tab1.col1 = tab2.col1
	UNION ALL
	SELECT tab1.col1, NULL
	FROM tab1
	WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
	ORDER BY col1

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

現行のデータベース以外への問い合わせ方法はありません。というのもPostgreSQLがデータベース仕様のシステムカタログを読み込むためで、そこには、たとえそのふりをするだけにしろ、データベースを越えて問い合わせをするすべがありません。

contrib/dblink はデータベース間(cross-database)の問い合わせを関数呼出しにより許します。もちろん、クライアントは同時に接続を別のデータベースへも張らなくてはならず、結果をクライアント側でマージしなくてはなりません。

4.25) 関数で複数のロウまたはカラムを返すにはどうしますか？

7.3では関数から、複数行のや複数カラムを簡単に返せます。 http://techdocs.postgresql.org/guides/SetReturningFunctions。

4.26)なぜ、PL/PgSQL 関数の中から一時テーブルを確実に create/drop することができないのでしょうか？

PL/PgSQL は関数の内容をキャッシュし、その不幸な副作用のため、もし PL/PgSQL 関数が一時テーブルにアクセスすると、そのテーブルはあとでドロップされ再作成されますが、関数が再び呼び出されると、キャッシュされているその関数の内容はまだ古い一時テーブルを依然として指しているからです。解決策は、 PL/PgSQL の中で EXECUTE を一時テーブルアクセスのために使うことです。これで、毎回クエリーのパースし直しを起こすでしょう。

4.27) どのようなリプリケーションオプションを利用できますか?

マスター／スレーブのリプリケーションオプションがいくつか利用可能です。これらのオプションではマスターのみがデータベースを変更でき、スレーブはデータベースを読むだけです。 http://gborg.PostgreSQL.org/genpage?replication_research の最後にそれらを一覧にしてあります。 マルチ-マスターのリプリケーションによるソリューションは http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php にて作業が進められています。

4.28) どのような暗号化オプションを利用できますか?

• contrib/pgcrypto SQL問い合わせの中で使うための沢山の暗号化を含みます。
• クライアントからサーバーへの転送をを暗号化する唯一の方法はpg_hba.confの中でhostsslを使うことによります。
• バージョン7.3 ではデータベースユーザのパスワードは保存される時に自動的に暗号化されます。 それより前のバージョンではpostgresql.conf中でPASSWORD_ENCRYPTIONを有効にする必要があります。
サーバーは暗号化ファイルシステムを使って走ることもできます。

PostgreSQLの拡張についての質問

5.1) 自分で書いたユーザ定義関数を psql の中で実行するとコア・ダンプしてしまうのはなぜですか？

問題は色々と考えられますが、まず最初に、作成したユーザ定義関数を単独のテストプログラムにして試してみて下さい。

5.2) PostgreSQL 用に書いたちょっと素敵な新しい型や関数を提供してプロジェクトに貢献したいのですが？

皆さんの行なった拡張を、pgsql-hackers メーリング・リストに送ってください。そして、ゆくゆくはそうした拡張が contrib/ サブディレクトリの中に入ることになるでしょう。

5.3) タプルを返す C言語の関数はどのように書きますか？

バージョン7.3以降のPostgreSQLでは、テーブルを返す関数を C, PL/PgSQL、そして SQL にて完全にサポートします。詳しくはプログラマガイドの情報を見てください。Cで定義された表を返す関数の例題がcontrib/tablefuncの中にあります。

5.4) ソース・ファイルを変更しました。再コンパイルしても変化が見られないのはなぜですか？

いくつかの Makefile がインクルード・ファイルに対して適切な依存関係を持っていません。make clean をしてからもう一度 make を行なわなくてはなりません。もし、GCC をお使いであれば configure の --enable-depend オプションを使って、コンパイラに依存関係を自動的に調べさせることもできます。

[訳注：
  日本語版の製作については以下の通りです。

  最終更新日:	2003年06月30日
  翻訳者:	桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>)

  このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):

		田仲 稔(Minoru TANAKA <Tanaka.Minoru at keiken.co.jp>)
		石井 達夫(Tatsuo ISHII <t-ishii at sra.co.jp>)
		齊藤 知人(Tomohito SAITOH <tomos at elelab.nsc.co.jp>)
		馬場  肇(Hajime BABA <baba at kusastro.kyoto-u.ac.jp>)
		岡本 一幸(Kazuyuki OKAMOTO <kokamoto at itg.hitachi.co.jp>)
		小菅 昭一(Shoichi Kosuge <s-kosuge at str.hitachi.co.jp>)
		山下 義之(Yoshiyuki YAMASHITA <dica at eurus.dti.ne.jp>)
		境 真太郎(Sintaro SAKAI <s_sakai at mxn.mesh.ne.jp>)
		生越 昌己(Masami OGOSHI <ogochan at zetabits.com>)
		石川 俊行(Toshiyuki ISHIKAWA <tosiyuki at gol.com>)
		本田 茂広(Shigehiro HONDA <fwif0083 at mb.infoweb.ne.jp>)
		せせ じゅん(Jun SESE <sesejun at linet.gr.jp>)
		神谷 英孝(Hidetaka KAMIYA <hkamiya at catvmics.ne.jp>)
		菅原 敦(Atsushi SUGAWARA <asugawar at f3.dion.ne.jp>)
		稲葉 香理(Kaori Inaba <i-kaori at sra.co.jp>)

  をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、
和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、その他、
直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの皆さんに感謝します。

  日本語版のこの文書は、以下からもたどれます。
	http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問)
	http://www.PostgreSQL.jp/subcommittee/jpugdoc/JPUG文書・書籍関連分科会
	http://www.linux.or.jp/JF/Linux JFプロジェクト

  なお、この和訳に関するご意見は(juk at PostgreSQL.jp)までお寄せ下さい。
]