diff options
Diffstat (limited to 'doc/FAQ_japanese')
| -rw-r--r-- | doc/FAQ_japanese | 78 |
1 files changed, 49 insertions, 29 deletions
diff --git a/doc/FAQ_japanese b/doc/FAQ_japanese index f6d86f10436..794f300831e 100644 --- a/doc/FAQ_japanese +++ b/doc/FAQ_japanese @@ -1,6 +1,6 @@ PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ) -原文最終更新日: Fri Jan 5 15:40:20 EST 2007 +原文最終更新日: Tue Mar 20 13:43:40 EDT 2007 現在の維持管理者: Bruce Momjian (bruce@momjian.us) Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp) @@ -37,6 +37,7 @@ Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp) 1.11) SQLはどうすれば学べますか？ 1.12) パッチを提供したり、開発チーム参加するにはどうすればよいですか？ 1.13) 他のDBMSと比べてPostgreSQLはどうなのですか？ +1.14) PostgreSQLは国毎の最新の夏時間の変更を扱いますか？ ユーザ・クライアントの質問 @@ -53,8 +54,8 @@ Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp) ？ 3.4) どのようなデバグ機能が使えますか？ 3.5) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか？ -3.6) PostgreSQLのアップグレードの手順はどうしますか？ -3.7) ハードウェアにはどんなコンピュータを使えばよいですか？ +3.6) PostgreSQLのアップグレードの手順はどうなりますか？ +3.7) ハードウェアにはどのようなコンピュータを使えばよいですか？ 操作上の質問 @@ -227,7 +228,7 @@ ftp://ftp.PostgreSQL.org/pub/ を使います。 1.6) 最新のリリースはどれですか？ -PostgreSQL の最新版はバージョン 8.2.1 です。 +PostgreSQL の最新版はバージョン 8.2.3 です。 我々は、1年毎にメジャーリリースを、数ヵ月ごとのマイナーリリースを行なうことを計 画しています。 @@ -426,6 +427,14 @@ http://www.postgresql.jp/PostgreSQL/references.html スタイルの使用許諾に外れない限り、PostgreSQLのコードを制限無しで商品に組み 込むことができます。 +1.14) PostgreSQLは国毎の最新の夏時間の変更を扱いますか？ + +合州国の夏時間の変更は、PostgreSQLのリリース8.0.4以降[4+]と、その後のメジャーリ +リース、たとえば 8.1 には含まれています。カナダとオー西部ストラリアの変更は、 +8.0.[10+], 8.1.[6+] および、その後のメジャーリリースのすべてに含まれます。8.0よ +り前のPosrgreSQLではオペレーティングシステムのタイムゾーンデータベースを夏時間 +情報のために使っています。 + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ユーザ・クライアントの質問 @@ -535,25 +544,34 @@ postmasterが同時接続できるバックエンドプロセスの制限数を増やす必要があります。 postgresql.conf の中の max_connections の値を変更して postmasterを再起動するこ とで可能になります。 -3.6) PostgreSQLのアップグレードの手順はどうしますか？ +3.6) PostgreSQLのアップグレードの手順はどうなりますか？ + +バージョン番号付けの方針については、http://www.postgresql.org/support/ +versioning をご覧ください。 -PostgreSQLチームはマイナーリリースではバグの修正しか行ないませんので、たとえば -7.4.8 から 7.4.9 へのアップグレードにダンプとリストアは必要ありません。したがっ -て、データベースサーバを一時的に停止して、アップデートしたバイナリをインストー -ルし、そして、サーバをリスタートするだけです。 +新しい機能を盛り込むPostgreSQLのメジャーリリースはだいたい年に1回程度行ないます +。メジャーリリースは、たとえば、8.1から8.2へのように、バージョン番号の1番目か2 +番目の部分を増やしてゆきます。 -全ユーザはできるだけ早く最新のマイナーリリースにアップグレードするべきです。す -べてのアップグレードにリスクはつきものですが、 PostgreSQLのマイナーリリースは、 -なるべく小さなリスクで一般的なバグの修正だけを目論んだものです。我々コミュニテ -ィの中ではアップグレードしないほうがもっとリスクが高いものと考えられています。 +PostgreSQLのメジャーリリースは通常、システムテーブルとデータの内部フォーマット +を変更します。これらの変更はたいていは複雑なのでで、データファイルの後方互換性 +を維持したりはしません。メジャーアップグレードのためには、データベースのダンプ/ +リロードが必要になります。 -しかし、メジャーリリース（たとえば、7.3 から 7.4 のような）では、システムテーブ -ルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更は -たいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することが -できません。メジャーアップグレードのためには、データベースのダンプ/リロードが必 -要です。 +マイナーリリースは、たとえば、8.1.5 から8.1.6へのように、バージョン番号の3番目 +の値を増やします。PostgreSQLチームは、マイナーリリースに対しては、バグフィクス +しか行ないません。すべてのユーザは、できるだけ最新のマイナーリリースに更新すべ +きです。アップグレードには、常にリスクがつきものですから、PostgreSQLのマイナー +修正リリースでは、頻繁に発生したり、セキュリティに関係したり、データがつぶれる +バグだけを修正し、アップグレードのリスクを最小限にとどめます。我々のコミュニテ +ィでは、アップグレードするリスクよりも、アップグレードしないリスクのほうが高い +と考えています。 -3.7) ハードウェアにはどんなコンピュータを使えばよいですか？ +マイナーリリースのアップグレードにはダンプとリストアの必要はなく、データベース +サーバを停止して、アップデートされたバイナリをインストールし、サーバをリスター +トします。 + +3.7) ハードウェアにはどのようなコンピュータを使えばよいですか？ PCハードウェアはほとんど互換性がありますので、ほとんどの人は、すべてのPCハード ウェアが同じ品質だと思い込む傾向があります。しかし、それは間違いです。ECC RAM、 @@ -656,25 +674,25 @@ VACUUM FULL tabをしたほうが良いかもしれません。 例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを考えてみましょ う。テキストの文字列の平均長さを20バイトと仮定すると、フラットファイルの大きさ は約2.8MB です。このデータを含む PostgreSQL データベースファイルの大きさは次の -ように約5.6MBと見積もることができます： +ように約5.2MBと見積もることができます： - 28 bytes: 各ロウのヘッダ(概算) + 24 bytes: 各ロウのヘッダ(概算) 24 bytes: 整数(int)フィールドとテキスト(text)フィールド + 4 bytes: ページ上のタップルへのポインタ ---------------------------------------- - 56 bytes per row + 52 bytes per row PostgreSQL のデータページサイズは 8192バイト(8KB)なので: 8192 bytes per page ------------------- = 146 rows per database page (切り捨て) - 56 bytes per row + 52 bytes per row 100000 data rows - -------------------- = 685 database pages (切り上げ) - 146 rows per page + -------------------- = 633 database pages (切り上げ) + 158 rows per page - 685 database pages * 8192 bytes per page = 5,611,520 bytes (5.6 MB) + 633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB) インデックスは、これほどのオーバヘッドは要求しませんが、インデックス付けされる データを含む以上、それなりに大きくなります。 @@ -939,8 +957,10 @@ contrib/dblink はデータベース間(cross-database)の問い合わせを関数呼出しにより許 4.18) 関数から複数のロウまたはカラムを返すにはどうしますか？ -集合を返す関数(Set Returning Functions): http://techdocs.postgresql.org/guides/ -SetReturningFunctions を使うと簡単です +集合を返す関数(Set Returning Functions): http://www.postgresql.org/docs/ +techdocs.17 + +を使うと簡単です 。 @@ -1017,7 +1037,7 @@ client_encodingを設定しておかないと、日本語を表示する際に文字化けがおきます。 [訳注： 日本語版の製作については以下の通りです。 - 最終更新日: 2007年01月07日 + 最終更新日: 2007年03月25日 翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): |