PostgreSQL v7.3 リリース 16
ストーリー by Oliver
COMMIT; 部門より
COMMIT; 部門より
Anonymous Coward曰く、"こないだ話題になったPostgreSQLの v7.3がリリースされた。開発本家ページや、日本のリンクサイト等で新機能の確認を。PostgreSQL v7.3 についてはイベントでも解説される模様。"
Anonymous Coward曰く、"こないだ話題になったPostgreSQLの v7.3がリリースされた。開発本家ページや、日本のリンクサイト等で新機能の確認を。PostgreSQL v7.3 についてはイベントでも解説される模様。"
Stableって古いって意味だっけ？ -- Debian初級
便乗～ (スコア:1, 参考になる)
以下、以前配布されていた資料より引用
------
SAP DB Compared to Other Open Source DBMS
mySQL and PostgreSQL
Simply do not play in the same league
Are not able to run SAP applications
Lack concepts like views or transaction handling (mySQL)
Lack OLTP performance for high volume workloads (mySQL,PostgreSQL)
SAP DB is the only Open Source DBMS for enterprise Applications
------
ツッコミどころはありますが、やる気は感じられます。
# オフトピ失礼
Re:便乗～ (スコア:3, 参考になる)
s/DMBS/DBMS/
SAP DB のリンク先:正しくはここ [sapdb.org]
基幹業務での使用に耐えうる(と称する)オープンソースDBMSが、既存の商用DBMSの在り方にどれだけ影響を及ぼすかが楽しみですね。
SAP DB 自体は、マルチバイトへの対応がUNICODE以外に無いのがチト痛いところです。
# テキストカラムに like 演算子を適用する設計はそもそもアレですが
Re:便乗～ (スコア:1)
http://www.sapdb.org/7.4/sap_db_support.htm [sapdb.org]
年間60,000ユーロ、ですか。(日本語で質問できるか、という問題は置くとしても。)
どこかサードパーティが、これより安い値段でまともなサポートを
提供しようという気になる代物なら、SAP DB も盛り上がるでしょうけれどね。
しばらく使ってないんですが (スコア:0)
VACUUMは必要ですが (スコア:2, 参考になる)
VACUUMしている最中でも並行してクエリを受け付けられるようになっていますよ。
...芸というものは一生勉強だと思っています...
Re:しばらく使ってないんですが (スコア:2, 参考になる)
PostgreSQL 7.1 から 7.2 への変更点 [sra.co.jp]
用途・規模によってVACUUMとANALYZEを分けるのが吉かと。
今、インストール中です。
留意点はマルチバイト対応がデフォルトになったこと。
スキーマとドメインの実装が有り難い所。
Re:しばらく使ってないんですが (スコア:3, 参考になる)
×7.2よりデメリットは減ってます。
Ｏ 7.2からデメリットが減ってます。
で、お詫びに簡単なメモを。
・VACUUM
UPDATEとDELETEの頻度と相談して定期的に。
読み書きOK。
・VACUUM FULL
大量にレコードを削除した場合や、表のサイズとして相談。非定期的に。
表の排他ロック。
・ANALYZE
レコードの追加・更新が多い場合に。EXPLAINでコストを見ながら、混んでない時間に。
読み出しロック。
気になる人は、トランザクションを走らせた時にシステムテーブルのpg_locksでも眺めてください。
ビュー (スコア:1)
ロック (スコア:1)
Re:ロック (スコア:1, 参考になる)
db=# VACUUM tablename;
だと、そのテーブルしかロックされませんので、
ロックと気づかずにいたのではないでしょうか。
db=# VACUUM;
だと、VACUUM文ひとつが１トランザクションとなり、
しかも他の操作を完全にブロックするレベルでですので、
システム管理テーブルを含む全テーブルが
ロックされてしまい、結構大変です。
Re:ロック (スコア:2, 参考になる)
// 日本語は難しい。
普通の VACUUM がロックしなくなって空き領域もきちんと再利用されるようになった、とはいえ、デフォルトでは 10000 ディスクページ分しか回収されないので、極端に update や delete が多いテーブルに対してたまにしか vacuum しないとやっぱりデータファイルが肥大化していってしまいます。
そんな時は MAX_FSM_PAGES パラメータを見直しましょう。また一度大きくなってしまったデータファイルは vacuum full しない限り小さくなりません。vacuum full は昔の vacuum 同様、table 全体をロックします。
また、インデックスに関してはまた別に管理しないといけません。ある程度立つとゴミがたまってきますので、こちらもサイズが大きくなってきたな、と思ったら drop/create しなおすなどのメンテナンスが必要です。
// こんな話は多かれ少なかれどの RDBMS にもありますね。
Only Jav^Hpanese available :-)
Re:しばらく使ってないんですが (スコア:1)
これを自動でやってくれるようになると嬉しいのだけど。
通常の VACUUM も ANALYZE もロックしないのではなかったでしたっけ。
ロックするのは VACUM FULL だった気が。
# ANALYZE もするのかな？短時間で終わるのであまり気にしてなかったけど。
ない…… (スコア:0)
手持ちの TurboLinux 用の spec ファイル（もと 7.2.3 用）だと、各種インタフェイス（バインディング？）と pgaccess がないなあと思って HISTORY を見てみると、
ということで、のきなみ独立してたのですね。管理は楽なんだろうけど、使う側としてはちょっとメンドくさいかも。
# 文句言ってるけど、お世話になっているので AC