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

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

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

1.7) 最新版はどれですか

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

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

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

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

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

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

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

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) バグレポートはどのように発信しますか？

バグを報告する仕方についてのガイドラインと方向づけがあるPostgreSQL 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/why-not-mysql.html にあります。

PostgreSQLは、Unixプロセスを起動することによりユーザー接続を操作します。 複数のバックエンド・プロセスが情報をロックしながらデータ・バッファーを 共有します。マルチCPUでは、簡単に複数のバックエンドをそれぞれのCPUで走 らせることができます。

信頼性(Reliability)

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

サポート(Support)

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

価格(Price)

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

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

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

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

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

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

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

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

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

PsqlODBC は PostgreSQL の配布に含まれています。それについてのさらに詳細な情報は ftp://ftp.PostgreSQL.org/pub/odbc/ から取得できます。

    [訳注:
	PsqlODBC の 日本語パッチを片岡裕生さん(kataoka@interwiz.koganei.tokyo.jp)が作られました:
	●http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/index.html
	現在、最新版は井上博司さんのサイトにあります。
	●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にあります。

http://www.phone.net/home/mwm/hotlist/にも、もう一つあります。

Web への拡張のためには、PHP が卓越したインターフェースとなっています。http://www.php.net/にあります。

    [訳注:
	  PHPに関する日本語の情報は、2000年4月19日に発足した日本PHPユーザ会のサイト
		http://www.php.gr.jp/
	あるいは、廣川 類さんのサイト
		http://www.geocities.jp/rui_hirokawa/php/
	にかなりまとめられています。
	  前田 充宏さんにより作られたPHP/FIの日本語パッチが様々な人の手を経てPHP3.0.7に適用されました。
	現在はPHPJ-DEVにて、
		http://php.jpnnet.com/
	佐藤さんを中心にマルチバイト拡張として作り直され、最新版はPHP-3.0.18に対応しています。
	  塚田 卓也さんは、PHP4 用の日本語関係の拡張モジュール
		ftp://night.fminn.nagano.nagano.jp/php4/
	を用意して下さってます。
	  本家の方で国際化のMLも立ち上がっています。
    ]

処理が複雑な場合、多くの人は Perl インターフェースと CGI.pm を使います。

    [訳注:
	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 にグラフィカル・ユーザインターフェースはありますか？ レポートジェネレータや埋め込み問い合わせ言語インターフェースはありますか？

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

ecpg という C 言語のための埋め込み SQL 問い合わせ言語インターフェースもあります。

2.4) PostgreSQL と通信するにはどんな言語が使えますか？

以下のものがあります:

• C (libpq, libpgeasy)
• C++ (libpq++)
• 埋め込みC (ecpg)
• Java (jdbc)
• Perl (perl5)
• ODBC (odbc)
• Python (PyGreSQL)
• TCL (libpgtcl)
• C Easy API (libpgeasy)
• 埋め込みHTML (PHP from http://www.php.net)

その他の利用可能なインターフェースは http://www.postgresql.org/interfaces.html にあります。

    [訳注：
	rubyの作者であるまつもと ゆきひろ(matz@ZetaBITS.COM)さんと、まつもと えいじ(ematsu@pfu.co.jp)さんが
	ruby の PostgreSQL インターフェースを作りました。現在の維持管理は斉藤 登さんがしています。
		http://webclub.kcom.ne.jp/mb/noborus/ruby/
        PgBash は 境田 雅明 さんが作った bash の PostgreSQL インターフェースです。
		http://www.psn.co.jp/PostgreSQL/pgbash/
	Bashコマンドラインでpostgres に問い合わせできます。
	Perl のモジュールは古くからある Pg と DBI ドライバの DBD::Pg とがあり、
	いずれも Edmund Mergl 氏によるもので CPAN サイトにあります。
	永安悟史さんは 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に許されるバックエンドのプロセス数が制限されているのは、 システムのリソースを使い果してしまうことを避けるためです。

6.5より前のバージョンのPostgreSQLではバックエンドの最大数は64でしたが、変更するには、include/storage/sinvaladt.hの中のMaxBackendId定数を修正した後に再構築が必要でした。

3.9) 自分のデータベース・ディレクトリにある pg_sorttemp.XXXファイルは何ですか？

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

一時的なファイルは自動的に消し去られるはずですが、もし、ソートの途中でバックエンドがクラッシュしてしまうとそうはなりません。そのときバックエンドがひとつも走ってなければ、pg_tempNNN.NNファイルを消しても大丈夫です。

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

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

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

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

操作上の質問

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

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

4.2) 最初の数ロウのみを SELECT するにはどうしますか？

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

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

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

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

4.4) テーブルからカラムの削除はどのようにしますか？

ALTER TABLE DROP COLUMN はサポートしていませんが、その代わりにこうします:

	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;

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

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

データベースの最大サイズ? 	制限無し (500GB のデータベースも存在します)
テーブルの最大サイズ?           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

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

• 検索文字列が文字列の最初にききます。たとえば：
• LIKE パターンが%.で始まらない
• ~ (正規表現) パターンは^.で始まらなければならない
• 検索文字列を文字クラスから始めることはできません。たとえば、[a-e]。
• ILIKE や ~* のように大文字小文字を区別しない検索は使えません。そのかわり、このFAQで後述する関数のインデックスが使えます。
• 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"          char            1 character
CHAR(#)         bpchar          指定された固定長となるように空白が詰められる
VARCHAR(#)      varchar         最大長のサイズを指定する、詰め物無し
TEXT            text            長さに上限の無いテキスト
BYTEA           bytea           可変長のバイト配列(null-byte safe)

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

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

CHAR()はいつも長さが同じ文字列を保存するのに最適で す。VARCHAR() は可変長の文字列を保存するのに最適ですが、 保存できる文字列の長さに制限があります。TEXT は長さに制限 の無い文字列の保存ためのもので、最大1ギガバイトです。 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 );

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

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

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

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

        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';

	ulimit -d 262144
	limit datasize 256m

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

	SELECT *
	FROM tab
	WHERE col1 IN (SELECT col2 FROM TAB2)

	SELECT *
	FROM tab
	WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)

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

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

  最終更新日:	2002年08月25日
  翻訳者:	桑村 潤 (Jun Kuwamura <juk@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>)

  をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、
  和訳のきっかけを作ってくれた 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プロジェクト
	http://www.sra.co.jp/people/t-ishii/PostgreSQL/doc-jp/

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