原文最終更新日: Fri Oct 29 20:22:37 EDT 1999
現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
この文書の最新版は PostgreSQL の WWW サイトの http://www.PostgreSQL.org で見ることができます。
Linux に特有の質問についての答えは:http://www.PostgreSQL.org/docs/FAQ-linux.html
に、
Irix に特有の質問についての答えは:http://www.PostgreSQL.org/docs/faq-irix.html
に、
HPUX に特有の質問についての答えは:http://www.PostgreSQL.org/docs/faq-hpux.html
にあります。
[訳注：日本語版については以下の通りです。 (以下、訳者による注意書きを [訳注： と ] で囲んで記します。) 最終更新日: 1999年12月10日 訳者: 桑村 潤 (juk@rccm.co.jp) このFAQの和訳の作成にあたって協力をしてくださった以下の方々、また、 きっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)の方々、 その他コメントを下さった多くの人々に感謝します。 田仲 稔さん(green@keiken.co.jp)、 石井 達夫さん(t-ishii@sra.co.jp)、 齊藤 知人さん(tomos@elelab.nsc.co.jp)、 馬場 肇さん(baba@kusastro.kyoto-u.ac.jp)、 岡本 一幸さん(ikko-@pacific.rim.or.jp) 小菅 昭一さん(s-kosuge@str.hitachi.co.jp) 日本語版のこの文書は http://www.rccm.co.jp/~juk/pgsql/ http://www.sra.co.jp/people/t-ishii/PostgreSQL/ http://www.linux.or.jp/JF/ からもたどれます。 なお、この和訳に関するご意見は桑村(juk@jp.postgresql.org)までお寄せ下さい。 ]
INを使う副問い合わせがとても遅いのですか？
PostgreSQL は POSTGRES データベース管理システムの改良版で、次世代DBMS 研究用のプロトタイプです。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を内包しつつ、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張したSQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースの利用ができます。
PostgreSQL の開発は PostgreSQL 開発者メーリングリストに参加しているインターネット上の開発者チームにより進められています。現在の座長は Marc G. Fournier ( scrappy@postgreSQL.org )です。(以下に参加の仕方があります。)現在、このチームがすべての現状と将来の PostgreSQL の開発の面倒を見ます。
PostgreSQL 1.01 の著者は Andrew Yu と Jolly Chen でした。その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に貢献しました。PostgreSQL の派生元コードである POSTGRES はカリフォルニア大学バークレー校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、職業プログラマたちの努力により作られました。
バークレーにおけるこのソフトウェアのもとの名前は Postgres でした。SQL の機能が追加された 1995 年にその名前は Postgres95 に変更されました。1996 年の終りにその名前は PostgreSQL に変更されました。
PostgreSQL は下記の著作権に従います。
[訳注：訳者は英語に不案内な上、法律については無知なので、以下に原文を残し訳注を付けます。]
PostgreSQL Data Base Management System
Copyright (c) 1994-6 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) 1994-6 カリフォルニア大学本校 このソフトウェアとその文書を、如何なる目的でも、無料で、使用許諾書無しに、 使用、複写、修正、そして、配布することへの許可を、上記の著作権表示、この段 落、および、これに続く二つの段落が、すべての複写に添付される限りにおいて、 ここにそれを認めます． たとえカリフォルニア大学が以下のような損害の可能性について言及していた としても．このソフトウェア及び文書の使用上，直接的・間接的・特別・偶然 もしくは必然的に，生じた失われた利益を含む損害に於いて，いずれの当事者 に対してもカリフォルニア大学は一切の責任を負いません． カリフォルニア大学は，特定目的のための商用性及び適合性の暗黙の保証を含 む，しかしそれに限定されることのない，いかなる保証も明確に放棄します． ここにおいて用意されたソフトウェアは「あるがまま」ということを前提とし， カリフォルニア大学は維持・補助・更新・改良・修正を用意する義務を負いま せん． ]
著者らは PostgreSQL のコンパイルとテストを次のプラットホーム上で行ないました。(これらのうちの幾つかはコンパイルに gcc が必要です)：
MS Windows プラットホーム上で、libpq C ライブラリ、psql、それとその他のインターフェースは コンパイル可能で、バイナリーが走ります。この場合、クライアントを MS Windows 上で走らせて、TCP/IP 経由でサポートされている Unix プラットホーム上で走るサーバと通信します。
Win32 libpq ライブラリと psql を作るために、win31.mak が配布に含まれてます。
現在、Cygnus Unix/NT 移植ライブラリを使って、PostgreSQL データベースサーバは Windows NT 上で動いています。配布に含まれるpgsql/doc/README.NTを御覧下さい。
http://surya.wipro.com/uwin/ported.html.にはU/Winを使う別の移植もあります。
PostgreSQL の元の anonymous ftp サイトです：
ミラーサイトについては、我々のメイン・ウェブページをご覧下さい。
[訳注:
以下は日本のミラーサイトです:
Japan: ftp://mirror.nucba.ac.jp/mirror/postgresql/pub
Japan: ftp://ring.ip-kyoto.ad.jp/pub/misc/db/postgresql/
Japan: ftp://ring.crl.go.jp/pub/misc/db/postgresql/
Japan: ftp://ring.saitama-u.ac.jp/pub/misc/db/postgresql/
Japan: ftp://ring.astem.or.jp/pub/misc/db/postgresql/
Japan: ftp://ring.exp.fujixerox.co.jp/pub/misc/db/postgresql/
Japan: ftp://ring.jah.ne.jp/pub/misc/db/postgresql/
Japan: ftp://ring.etl.go.jp.jp/pub/misc/db/postgresql/
Japan: ftp://ring.asahi-net.or.jp/pub/misc/db/postgresql
Japan: ftp://ring.so-net.ne.jp/pub/misc/db/postgresql/
Japan: ftp://ring.aist.go.jp/pub/misc/db/postgresql
]
カリフォルニア大学バークレー校からの PostgreSQL の公式なサポートはありません。サポートはボランティアの努力を通じて維持されています。
主要なメーリング・リストは: pgsql-general@postgreSQL.orgです。PostgreSQL に関することであれば議論ができます。このリストへの参加のは、電子メールの本文(Subject 行ではありません)に：
subscribe
end
と書いて、pgsql-general-request@postgreSQL.org へ送って下さい。
ダイジェスト版のメーリング・リストもあります。このリストへの参加は "本文"に：
subscribe
end
ダイジェスト版は、メインリストが受信するメッセージ 30k 程度溜る毎にダイジェスト版リストのメンバーに送付されます。
バグのメーリングリストも利用できます。このリストへの参加は "本文"といっしょに： bugs-request@postgreSQL.org へ電子メールを送って下さい。
開発者の議論のためのメーリングリストも利用できます。このリストへの参加は電子メールの本文に：
subscribe
end
と書いて、hackers-request@postgreSQL.orgへ電子メールを送って下さい。
PostgreSQL についてもっと詳しく知りたければ、次の postgreSQL WWWホームページからたどれます：
http://postgreSQL.org
IRC チャンネルも EFNet にあり、そのチャンネルは #PostgreSQL です。
unix コマンドでirc -c '#PostgreSQL' "$USER" irc.phoenix.net
を使います。
[訳注:
日本語のメーリング・リストを SRA Inc. の石井達夫さんが主催して
います。このリストの購読は、本文の１行目に：
subscribe
と書いて pgsql-jp-request@sra.co.jp 宛に電子メールをお送り下さい。
詳細は、
http://www.sra.co.jp/people/t-ishii/PostgreSQL/info.html
を御覧下さい。また、この ML のアーカイブは、
http://www.sra.co.jp/people/t-ishii/PostgreSQL/archive.html
で御覧になれます。
また、日本PostgreSQLユーザー会のウェブサイトは、
http://www.jp.postgresql.org
にあります。
]
PostgreSQL のための商用サポートは http://www.pgsql.com/で受けられます。
[訳注:
日本でも、
SRA Inc. オープンシステム事業部 にて
サポートが開始されました。
]
PostgreSQL の最新版はバージョン 6.5.2 です。
我々は、4カ月毎にメジャーリリースをすることを計画しています。
配付の中に、幾つかのマニュアルとオンライン・マニュアル(マニュアル・ページ)および幾つかの小さなテスト例題が含まれます。/doc ディレクトリを御覧下さい。
psql は、型、演算子、関数、集約、その他の情報を見せる、幾つかの素晴らしい \d コマンドを持ちます。
ウェブサイトには、さらにもっと文書があります。
PostgreSQLは拡張されたSQL-92のサブセットをサポートします。 我々のページの TODO に、既知のバグ、欠落機能、および、将来計画のリストがあります。
素晴らしい学習書には、 http://w3.one.net/~jhoffman/sqltut.htm と http://ourworld.compuserve.com/homepages/Graeme_Birchall/HTM_COOK.HTM.
とがあります。その他に、 "Teach Yourself SQL in 21 Days, Second Edition" が、 http://members.tripod.com/er4ebus/sql/index.htm にあります。
多くのユーザに、 The Practical SQL Handbook, Bowman et al., Addison Wesley が好評です。 その他に、Lan Times Guide to SQL, Groff et al.,Osborne McGraw-Hill のようなのもあります。
[訳注； http://www.SRA.co.jp/people/t-ishii/PostgreSQL/doc-jp/index.html に石井さんによる日本語の参考文献の紹介があります。 http://www.wakhok.ac.jp/DB/DB.html丸山不二夫氏のUNIX データベース入門 ]
対応してます。西暦2000年より後の日付でも紀元前2000年より前の日付でも簡単に扱えます。
1番目に、最新のソースをダウンロードし、我々のウェブサイトか配布に含まれている PostgreSQL Developersの文書を読みます。 2番目に、pgsql-hackers と pgsql-patches メーリング・リストを購読(subscribe)します。 3番目に、高品質のパッチをpgsql-patchesに発信します。 およそ十人ちょっとの人達がいわゆるPostgreSQL CVSアーカイブの COMMIT 権限を持っています。 その人達が沢山の高品質のパッチを発信してしまうので、現在のコミッター達は追い付くのが大変ですが、我々は彼らがコミットしたパッチは高品質であると確信してます。
"bug-template" ファイルの項目を満たして、bugs@postgreSQL.orgに送って下さい。
その前に http://postgreSQL.orgにある最新の FAQ をチェックして下さい。
それと同時に ftp サイト ftp://ftp.postgreSQL.org/pubで、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。
ソフトウェアを計る方法にはいくつかあります。機能、性能、信頼性、サポート、 および、価格です。
PostODBC と OpenLink ODBC の二つの ODBC ドライバーが利用可能です。
PostODBC は PostgreSQL の配布に含まれています。それについてのさらに詳細な情報は http://www.insightdist.com/psqlodbc から得られるでしょう。
[訳注:
PsqlODBC の 日本語パッチを片岡裕生さん(kataoka@interwiz.koganei.tokyo.jp)が作られました:
●http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/index.html
]
OpenLink ODBC は http://www.openlinksw.com/から入手できます。標準的な ODBC クライアント・ソフトウェアで使えますので、支援しているすべてのプラットホーム(Win, Mac, Unix, VMS)から PostgreSQL の ODBC が利用できます。
たぶん彼らは、商用品質のサポートの必要な人々に売っていると思いますが、フリーウェア版はいつでも入手可能のようです。質問は、postgres95@openlink.co.ukにお願いします。
データベースを裏に持つウェブページについての素晴らしい紹介が、
http://www.webtools.com にあります。
http://www.phone.net/home/mwm/hotlist/にも、もう一つあります。
ウェブへの拡張のためには、PHP が卓越したインターフェースとなっています。http://www.php.netにあります。
[訳注:
PHPに関する日本語のサイトは広川さんのところにあります。
前田充宏さん(mitsu@cni.co.jp)により作られましたPHP/FIの日本語パッチhttp://pg.cni.co.jp/が様々な人の手を経てPHP3.0.7に対応されました。現在はPHPJ-DEV（http://php.jpnnet.com/）にてマルチバイト対応拡張として作り直されてPHP-3.0.12に対応しています。
]
PHP は簡単な内容に対しては素晴らしいのですが、より複雑な場合の多くは perl インターフェースと CGI.pm が使われています。
perl を使った WDB を基にした WWW ゲートウェイはhttp://www.eol.ists.ca/~dunlop/wdb-p95からダウンロードできます。
pgaccess と呼ばれる素晴らしいグラフィカル・ユーザ・インターフェースがあり、この配布と共に出荷されます。Pgaccess にはレポート・ジェネレータもあります。ウェブページはhttp://www.flex.ro/pgaccessです。
ecpg という C 言語のための埋め込み SQL 問い合わせ言語インターフェースもあります。
以下のものがあります:
[訳注：
そのほか ruby のインターフェースもあります。
ruby の作者である、まつもと ゆきひろ(matz@netlab.co.jp)さんと、
まつもと えいじ(ematsu@pfu.co.jp)さんが ruby の PostgreSQL インター
フェースを作りました。日本語 PostgreSQL ML のアーカイブより、
http://www.sra.co.jp/people/t-ishii/PostgreSQL/archive.html
"Subject: [pgsql-jp 2446] PostgreSQL ruby module" を御覧ください。
ruby については、 http://www.netlab.co.jp/ruby/jp/ を御覧下さい。
]
WARN:heap_modifytuple: repl is 9というメッセージが出ていればこれが問題です。)
簡単な方法は、 configure を走らせる時に --prefix オプションを指定することです。 もし、それをするのを忘れたときは、Makefile.global 修正して POSTGRESDIR をそれに合わせるか、あるいは、Makefile.custom をつくりそこで POSTGRESDIR を定義して下さい。
さまざまな問題が考えられますが、まず最初にあなたのカーネルに system V の拡張がインストールされているかを確認して見てください。PostgreSQL はカーネルによる共有メモリとセマフォのサポートを必要とします。
カーネルが共有メモリーを持つ設定になっていなかったか、でなければ、カーネルに対して使える共有メモリの大きさを大きく設定する必要があります。具体的な大きさは、使っているアーキテクチャとpostmaster を走らせるときに設定するバッファの数とバックエンドプロセスに依存します。ほとんどのシステムでは、既定値のバッファサイズで、少なくても約1MBが必要です。
もしエラーメッセージがIpcSemaphoreCreate: semget failed (No space left on device)であれば、カーネルが十分なセマフォーを使えるように構成されていません。Postgresは潜在的なバックエンドプロセス毎に一つのセマフォーを必要とします。とりあえずの解決策はpostmasterを始動する時に、バックエンドプロセスの数をより少なく制限をすることです。既定値の32より小さな数のパラメータを-Nで使います。より恒久的な解決策は、カーネルのSEMMNS と SEMMNI パラメータを増やすことです。
もし、エラーメッセージがなにか他のものであれば、カーネルの構成でまったくセマフォーのサポートをしていないかもしれません。
既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postmaster 起動に -i フラッグを加え、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。
既定値の設定ではローカルマシンからの unix ドメインのソケット接続しか許しません。TCP/IP 接続を可能にするには postmaster が -i オプションで開始されていて、pgsql/data/pg_hba.conf ファイルに適切なホストの記載が追加されていることを確認してください。
オンラインマニュアルで pg_hba.conf を見て下さい。
ユーザ id 0 (root) でデータベース・ユーザを創るべきではありません。そうするとユーザはデータベースにはアクセスできません。これは、すべてのユーザがデータベース・エンジンの中にオブジェクト・モジュールを動的に結合できるようにするかわりの保全対策です。
この問題はセマフォをサポートするように設定していないカーネルで起こり得ます。
確かに索引は問い合わせの速度を増します。EXPLAINコマンドで PostgreSQL がどのようにあなたの問い合わせを翻訳しているかを見ることができ、そして、どの索引が使われているかを見ることができます。
もし INSERT を沢山しているとすると、COPY コマンドを使った大きなバッチ処理でそれを行なうことを考慮して下さい。これは、単独の INSERT を別々に行なうよりもっと速いです。次に、BEGIN WORK/COMMIT のトランザクション・ブロックの中にはない文を、それらのトランザクションの中に入れることを考えてみてください。幾つかの文を一つのトランザクション・ブロックの中で行なうことを考えて下さい。これによりトランザクションのオーバーヘッドが縮小されます。また、大きなデータの変更を行なう際はインデックスを一度外して、作り直すことを考えてみて下さい。
行なえるチューニングには幾つかあります。postmaster を -o -F オプションで起動することによって、fsync() を無効にするオプションを使うことができます。これによって、すべてのトランザクション毎に fsync() でディスクを更新するのを止めさせます。
postmaster -B オプションを使ってバックエンド・プロセスにより使われる共有メモリ・バッファを大きくすることもできます。もし、このパラメータを高くしすぎると、カーネルの共有メモリー空間の制限値を越えてしまっうために postmaster は走らないでしょう。既定値では、それぞれのバッファの大きさは 8K で、バッファ数は 64 です。
バックエンドを -S オプションを使って、それぞれのバックエンド・プロセスが一時的な並べ替えによって使うメモリの最大サイズを増やすこともできます。 その -S の値はキロバイト単位で、既定値は 512 (すなわち、512K)です。 その値をあまり大きくし過ぎることは賢くありません、問い合わせが幾つかの競合する並べ変えを実行するときにメモリーを使いはたしてしまうかもしれません。
また、CLUSTER コマンドを使って、基表のデータを索引に合わせるためにグループ化することもできます。
PostgreSQL は、デバッグのために意味のある、状態情報を報告する幾つかの機能を持ちます。
まず、--enable-cassert オプションで configure を走らせます。そうしてコンパイルすることにより、沢山の assert() が、バックエンドの進捗状況を監視し、何か予期せぬことが起きるとプログラムを停止するようになります。
postmaster と postgres の両方で幾つかのデバッグ・オプションの利用ができます。まず次のように、postmaster を起動するときはいつでも、次のように標準出力とエラー出力をログ・ファイルに送るようにしてあることを確かめて下さい。
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
これにより PostgreSQL の最上部のディレクトリに server.log ファイルが置かれます。このファイルはサーバーが遭遇した問題やエラーについて有用な情報を含みます。Postmaster は更に詳細な情報を報告するための -d オプションを持ちます。その -d オプションは、デバグ・レベルを指定します。高いデバグ・レベルでは、大きなログファイルを生成することに注意しなくてはなりません。
コマンド行から、実際に postgres のバックエンドを走らせることも、また、SQL 文を直接入力することもできます。これは、デバッグの目的のためにだけお勧めします。セミコロンではなく、改行が問い合わせを完結することに注意して下さい。もし、デバッグ・シンボルを一緒にコンパイルしていたならば、何が起きているかを診るのにデバッガが使えるでしょう。バックエンドが postmaster から起動されたのではなく、同一環境で走るわけではではないので、ロッキング／バックエンドの相互関係の問題では重複は起こらないでしょう。あるオペレーティング・システムでは、問題を診断するために、走っているバックエンドに直接取り付けることができます。
postgreSQL プログラムには、デバッグと性能測定にとても役に立つ -s、-A、-t 等のオプションがあります。
なんという関数が実行時間を食っているかを見るために、プロファイリングでコンパイルすることも可能です。そのバックエンドのプロフィール・ファイルは pgsql/data/base/dbname ディレクトリに格納されるでしょう。クライアントのプロフィールは現行ディレクトリに置かれるでしょう。
postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があります。
Postgres 6.5.*では制限の既定では32プロセスです。適切な-Nの値でpostmasterを再起動することにより増加させることができます。既定の構成では-Nは1024と同じ大きさに設定できます。もし、もっと必要であればinclude/config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。
もし、-N を 32よりも大きくするのであれば、-Bも既定の64を越すように増加させることを考慮すべきです。沢山の数のバックエンドプロセスは、様々なUnixカーネルの構成パラメータも増やすことが必要になるでしょう。共有メモリーブロックの最大の大きさも確認事項に含まれ、SHMMAX, セマフォーの最大数、 SEMMNS と SEMMNI, プロセスの最大数、NPROC ユーザ毎の最大プロセス数、MAXUPRC 開くファイルの最大数、NFILEとNINODE。 その理由は、Postgresが許されるバックエンドのプロセス数の制限を持つためで、それによりシステムの資源を使い果してしまうことに堪えることができます。
6.5よりも前のバージョンのPostgresではバックエンドの最大数は64で、その変更には、include/storage/sinvaladt.hの中のMaxBackendId定数を定めた後に再構築が要求されました。
それらは問い合わせ実行部によって生成された一時的なファイルです。例えば、もし order by 句を満たす為にバックエンドの -S パラメータで許可したよりも大きなスペースがソートに必要だとすると、幾つかの一時ファイルが溢れたデータを保持するために一時(temp)ファイルが生成されます。 tempファイルは自動的に消し去られるはずですが、もし、ソートの途中でバックエンドが潰れてしまうとそうなりません。もし、その時トランザクションが走ってなければ、pg_tempNNN.NNファイルを消しても安全です。
現在、ユーザ・グループを設定する簡単なインターフェースはありません。明示的に pg_group テーブルを insert/update しなければなりません。例えば次のようにします：
jolly=> insert into pg_group (groname, grosysid, grolist)
jolly=> values ('posthackers', '1234', '{5443, 8261}');
INSERT 548224
jolly=> grant insert on foo to group posthackers;
CHANGE
jolly=>
pg_group のフィールドは以下のとおりです：
ロケールの設定を確かめて下さい。PostgreSQL は postmaster プロセスを走らせたユーザーのロケールの設定を使います。postgres とpsql には SET コマンドがあり、データ書式を制御できます。これらをあなたの操作環境に合わせて設定して下さい。
詳述は、オンラインマニュアルで DECLARE を見て下さい。
オンラインマニュアルでFETCHをご覧頂き、SELECT ... LIMIT....を使ってみて下さい。
たとえ、欲いのは最初の数行だけでも、すべての問い合わせを評価しなくてはならないかもしれません。。ORDER BY を持った問い合わせを考えてみて下さい。 もし、ORDER BYに合う索引があるとすると、PostgreSQLは要求された最初の数行だけを評価できるかもしれませんし、あるいは、意図した行が生成されるまで、すべての問い合わせが評価されなければならないかもしれません。
psqlのソースコード pgsql/src/bin/psql/psql.c ファイルを読むことができます。 それは、psqlのバックスラッシュコマンドのための出力となるSQLコマンドを含んでいます。 Postgres 6.5 を始めるにあたり、psql を -E オプションで開始すれば、与えたコマンドを実行するための問い合わせを出力します。
ファイル pgsql/src/bin/psql/psql.c を見て下さい。その中に、psql のバックスラッシュコマンドで生成される SQL コマンドもあります。
ALTER TABLE DROP COLUMN はサポートしていませんが、その代わりにこうします:
SELECT ... -- 削除したい列以外の列をすべて選択します。 INTO TABLE new_table FROM old_table; DROP TABLE old_table; ALTER TABLE new_table RENAME TO old_table;
行の大きさは 8キロ・バイト(8K)に制限されていますが、これはinclude/config.hを編集しBLCKSZを変えることにで変更できます。8K を越える属性を使うときは、ラージ・オブジェクト・インターフェースを使ってみて下さい。
[訳注：8K は 8*1024=8192]
行は 8k の境界をまたがることができないので、5k の行でも 8k の保存領域が必要です。 テーブルとデータベースの大きさの制限はありません。数十ギガバイトのデータベースは沢山あり、また、おそらく幾つかは数百ギガバイトです。
各行に二つづつ整数を持つ 300,000行のファイルを考えてみましょう。ただのファイルでは 2.4MB です。このデータを含む PostgreSQL データベースファイルの大きさは次のように約14MBと見積もることができます：
36 bytes: 各行のヘッダ(概算)
+ 8 bytes: 各4バイトの二つの整数(int)フィールド
+ 4 bytes: ページ上のタップルへのポインタ
----------------------------------------
48 bytes per row
PostgreSQL のデータページサイズは 8192(8KB)バイトなので:
8192 bytes per page
------------------- = 171 rows per database page (切り上げ)
48 bytes per row
300000 data rows
-------------------- = 1755 database pages
171 rows per page
1755 database pages * 8192 bytes per page = 14,376,960 bytes (14MB)
索引はかなりのオーバーヘッドとなるので含めていませんが、索引付けされたデータを持つとすると、やはりそれなりに大きくなります。
psql は様々なバックスラッシュ・コマンドを持ち、こういった情報を表示します。それらを見るには \? を使って下さい。
また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。
PostgreSQL は統計情報を自動的には保守しません。統計情報を更新するためには、明示的に VACUUM を呼び出さなくてはなりません。統計情報が更新された後は、最適化部がテーブルに何行あるかを知って、索引を使うべきかの決定をより良く下します。オブティマイザはテーブルが小さくて連続走査の方が速いであろう場合は索引を使いませんのでご注意下さい。 カラム指定の最適化の統計のためにVACUUM ANALYZEを使います。VACUUM ANALYZEは複雑な複合結(multi-join)合問い合わせのために大切ですので、オブティマイザはそれぞれのテーブルから返される行の数を見積もることができ、特定の結合順序を選びます。バックエンドはそれ自身ではカラムの統計を保持しないので、定期的にそれらを直すためにVACUUM analyze を走らせなくてはなりません。
索引は ORDER BY 操作のためには使われません。
LIKE あるいは ~ のような切札(wild-card)演算子を使う時は索引は、もし、検索の始まりが文字列の始まりで固定されている場合のみ使われます。ですから、索引を使うには%で始まらない LIKE 検索 と ^ で始まる~(正規表現)にします。もし、localeが埋め込まれていれば、索引はワイルドカード検索には使えません。
もし、システムが已然として索引を見ないとすれば、不適切な *_ops 型のフィールドに索引をつくってしまったからでしょう。たとえば、CHAR(4) のフィールドをつくったのに、char_ops index type_class を指定してしまったときなどです。
どの型のクラスが利用可能かにつては、オンラインマニュアルで create_index を見て下さい。フィールドの型と合うはずです。
不適切な索引がつくられても、 PostgreSQL は警告を出しません。
索引は ORDER BY 操作のためには使われません。
オンラインマニュアルで explain を見て下さい。
R-tree 索引は空間的なデータに索引を付けるために使われます。ハッシュ索引では範囲の検索ができません。また、B-tree 索引では、１次元でしか範囲の検索ができません。R-tree インデックスであれば多次元のデータを扱えます。たとえば、もし R-tree インデックスを point 型の属性に付けることができるとするとシステムは、長方形に囲まれた点をすべてを選択するというような問い合わせに、より効率良く答えられます。
組み込まれている R-Tree でポリゴンやボックスを操作できます。理論的にはR-tree はもっと高い次元を操作するようにも拡張できます。実質的には、R-tree の拡張にはちょっとした作業が必要でして、現在、我々はそれをどのようにするかについての文書を持っていません。
R-Tree の設計の原典となる権威ある論文は:
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
で、この論文は、Stonebraker 教授の "Readings in Database Systems" でも取り上げられています。
[訳注：
奈良先端大の石川佳治さんより日本 PostgreSQL ML にて文献を紹介して
頂きました。この ML のアーカイブ
http://www.sra.co.jp/people/t-ishii/PostgreSQL/archive.html
から "Subject: [postgres95 801] spatial data structures" を御覧下さい。
]
PostgreSQL の GEQO モジュールは、遺伝的アルゴリズム(GA)で、沢山のテーブルの結合する、問い合わせ最適化問題を解くことを意図しています。これにより、しらみつぶし探索を行なうことなしに、大きな結合(join queries)を扱うことができるようになります。
さらに詳しい情報については文書を御覧下さい。
~と~* のことだと思います。 psql の \do コマンドをご覧下さい。
IS NULL と IS NOT NULL でカラムをテストしてみて下さい。
Type Internal Name Notes -------------------------------------------------- CHAR char 1 character CHAR(#) bpchar 指定された固定長となるように空白が詰められる VARCHAR(#) varchar 最大長の大きさを指定する、何も詰められない TEXT text 長さの制限は最大行長による BYTEA bytea バイトの可変長配列
内部操作を行なうときには、内部名を使う必要があります。
上記の型のうち後の４つの型は "varlena" 型です(すなわち、最初の４バイトがデータ長で、それの後に実際のデータが続きます)。char(#) はどれだけデータがフィールドに保存されようとも最大のバイト数を確保します。text と varchar(#) と BYTEA 等はすべてディスク上で可変長となる文字型で、このため、それらを使うためには小さな性能上のペナルティがあります。特にそのペナルティは、この型が最初に現れたカラムの後の任意のカラムにアクセスするときにあります。
PostgreSQL は SERIAL データ型をサポートします。カラム上に通番と索引を自動作成します。通番についてのさらなる情報は、オンラインマニュアルの create_sequence を御覧下さい。
また、各行のoidフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてりロードする必要がある場合は、oidを温存するためにpg_dumpの -oを使うか、または、COPY WITH OIDSオプションを使う必要があります。
Oid とは一意の行 ID に対する PostgreSQL の答えです。PostgreSQL の中でつくられるすべての行は一意の oid を得ます。initdb で(backend/access/transam.h から)発生される oid はすべて 16384より小さな値です。initdb 後のすべての oid (ユーザ作成)はそれ以上の値になります。既定値では、これらすべての oid はテーブル内やデータベース内に留まらず、PostgreSQL のそのインストレーション全体内で一意であります。
PostgreSQL はテーブル間の行を結びつけるために、そのシステム・テーブル内に oid を使います。この oid は特定のユーザの行を識別するためや結合の中で使われることができます。oid の値を保存するためには oid 型をカラムに使うことを奨めます。他の内部カラムを見るにはオンライン・マニュアルで sql(l) を御覧下さい。より速くアクセスするために oid フィールドに索引を作ることができます。
Oid は、全てのデータベースから使われる中央部分からの全ての新しい行に割り当てられます。もし、oid を他の何かに変えたかったり、あるいは、元の oid でテーブルをコピーしたかったとしても、それを行なうことはできません。
CREATE TABLE new_table(old_oid oid, mycol int);
SELECT INTO new SELECT old_oid, mycol FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
Tid は特定の物理行をそのブロックとオフセット値で識別するために使われます。Tid は行が修正されたり再ロードされると変わります。それらの tid は、物理行を指すために索引記載で使われます。
あるソースコードや古い文書の中では、あまり一般的ではなくなった用語を使ってます。それらは；
システムの仮想メモリーを全て使い果たしてしまっている可能性があるか、あるいは カーネルがあるリソースについて低い制限値を持っている可能性がありあmす。 postmaster を開始する前にこれを試してみて下さい：
ulimit -d 65536
limit datasize 64m
シェルによって、これらのうちの一つがゆくでしょうが、それは、プロセスのデータセグメントの限界をより高く設定するので問い合わせが完成のを許すでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後に作られる全てのサブプロセスについて適用されます。それでも、SQL クライアントで問題があれば、クライアントを開始する前のバックエンドがとても多くのデータを返そうとしているのでしょう。
psql から select version(); をタイプします。
ラージ・オブジェクト操作をするときは、前後にBEGIN WORKとCOMMITを付ける必要があります。すなわち、lo_open ... lo_closeで取り囲みます。
文書ではいつもlo_openはトランザクションに包み込まれているとしてありますが、6.5より前のバージョンのPostgreSQLではこの規則に従っていません。あなたが、壊したかのように言って、自分で失敗していることが間々あります。
現在のPostgreSQLでは、トランザクションのコミットの時にラージ・オブジェクト・ハンドルを閉じることにより、強制的に規則を実行します。そして、それはトランザクションの中でないときは一時的にlo_openコマンドの成立となります。それで、最初にハンドルに対して何かをしようとすると、invalid large obj descriptorとなります。それで、（少なくともほとんどの時間）働いていたコードは、トランザクションを使うのを失敗すると、エラーメッセージを生成します。
もし、ODBCのようなクライアントインターフェースをお使いなら、auto-commit offを設定する必要があるかもしれません。
次のようにしたくなるでしょう：
create table test (x int, modtime timestamp default 'now');
CREATE TABLE test (x int, modtime timestamp default now() );
now() を呼ぶことで、デフォルト時間が表の作成時に計算されてしまうのを避けて、挿入時まで遅らせます。post-6.5.* リリースではこれで問題が無いと信じています。
INを使う副問い合わせがとても遅いのですか？
現在、外部問い合わせの各行について副問い合わせの結果を連続走査することにより、副問い合わせを外部問い合わせに結合しています。当面はINをEXISTSで置き換えることです。たとえば、
元の：
SELECT *
FROM tab
WHERE col1 IN (SELECT col2 FROM TAB2)
SELECT *
FROM tab
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
問題は色々と考えられます。まず最初に、お作りになったユーザ定義関数を単独のテストプログラムにして試してみて下さい。また、type_in() や type_out()関数の実行中のように、フロントエンドがデータを待っている時に elog NOTICES を送っていないか確かめて下さい。
[訳注：elog は error logging です。]
palloc されていない何かを pfree しようとしています。malloc/freeとpalloc/pfreeとを混在させないようにご注意下さい。
皆さんの行なった拡張を、pgsql-hackers メーリング・リストに送ってください。そして、ゆくゆくはそうした拡張が contrib/ サブディレクトリの中に入ることになるでしょう。
原理的には可能ですが、これには極端な妙技を要しますので、著者らは未だやったことがありません。。
幾つかの Makefile がインクルード・ファイルに対して適切な依存関係を持っていません。make clean をしてからもう一度 make を行なわなくてはなりません。