語りません？

語ることがない。
石井君のページにでも行ってくれ。

ひょっとして、結論が出てしまったのでしょうか？

ポストグレは遅いよ。ていうか海外ではぜんぜん人気ないし。
やっぱマイでしょ、マイ。

君たち、僕の著書をよんでないようだね(藁

痛ずぎ....

8K制限なくなった…

みなさん、こんなとこで勉強しないで、僕がコンサルしてあげるよ。タダとは言わないからさ。

>>11
oracleと同等の性能出せるんなら考えてもいいよ。

OracleだろーがPostgreSQLだろーがMySQLだろーがはたまたInterBaseだろーが
要は適材適所。

別にPostgeSQLがOracleと同等の性能を出す必要は無し。

コンサル受ける必要は全く無いが（ｗ

vacuum が無くなればそれなりなんだけどな。>pgSQL
けどモノは使いようでメンテ必須という名目で保守契約結ぶとか
バックアップきっちり取れるとか悪いことばかりじゃないし。

取りあえずｄｂに金出さない貧乏クライアントは逝ってよし。

遊ぶだけなのに何百万も払いたくない＞Oracle

ほかの板だと、Oracle劇遅っつーのが、一般的見解なんだが、
ここは、Oracle最高っつー奴らばかりなのか？

ORACLE最高とかPostgres最強とかそんなことどーでもいいんだけどさ・・
やっぱ低レベルだわここの人達。。。

>>18
「語れ」しかいえないお前が一番低レベル。
「語れ」だけで高レベルな情報を得ようというのは虫が良すぎ。

まぁ、ここの人たちってさ、>>7みたいに、理由もなく何かを貶めて、
自己のアイデンティティーを確立しようとするような奴らが多いからさ、
そのへん割り引いてくれよ。

>>20
7もだが4も理由無しだな。どっちもどっち。

でもさー、何でデータベースの話になるとすぐ
Oracle vs PostgreSQL
PostgreSQL vs MySQL
みたいに実装系の比較の話になっちゃうの？
ほかに話すこといろいろありそうじゃん。

データベース板とか作ってもらったら？
隔離板になっちゃうかもしれないけどね。

でさー、こういう実装系の話をするときって、
・ある実装系が向いている仕様にはどんなものがあるか？
・ある実装系が向いていない仕様にはどんなものがあるか？
って観点で話さないと全然意味ないと思うよ。どんな実装系にだって設計思想があって、
それによって得意・不得意が出てくるんだから。

例えばデータサイズで言えば、
・単一ファイルシステムのサイズの限界があるか？
　yes: PostgreSQL, MySQL
　no: Oracle
となる以上、ファイルシステムの上限 (例えば 4GB) を超えるデータを MySQL 等で
扱うのはおかしいって話だよね。

逆に、オブジェクト指向言語実装系において、あるオブジェクトを永続化させるのに
便利なデータベースは？って問題なら
Yes!!: PostgreSQL (テーブル定義に継承が利用できるので、クラス定義と同じ構成の
　　　　テーブルを作成できる）
Yes: Enterprise Edition なら、オブジェクト型 (View) の定義ができる
No: その他（自分でインピーダンス不整合を解消する必要がある）
という風になるでしょ？だからこういった言語処理系を前提にしたならば、PostgreSQL か
Oracle かって話しになることが多いだろうね。

こういう前提条件無視してまともな議論になるはずがないんだと思うけど？

あとさー、最近のトレンドは「データベース抽象化」でしょ？
つまり、どのデータベースの実装系かってことを意識しないですむようにコーディング
するのが普通になってきているわけだよね。

何でこんなことをするかって言うと、
・開発時のデータベースと運用時のデータベースが違う（高くて買えない場合等）
・データベースに求められる仕様が変更される（例えば性能から安定性へ変わった場合）
という場合がありうるので、移植の手間を省くためにそういうことをするわけだ。さらに
抽象化は、そのためのクラスを通じて行うけど、これを大勢が何度も使うことによって
クラスの品質と使い勝手が向上して、より再利用しやすくなるって副作用もあるよね。

そうだとすると、そんな PostgreSQL はどうよ？とか MySQL はどうよ？的な質問は
意義を失ってくると思うんだが、どうよ？
# だいたい大半の人間は標準 SQL の範囲内でしか SQL 使ってないでしょ？関数とかは
　実装依存になるけど、じゃあ CASE とか /*++ とか使ってる人ってどのくらい
　いるんだろ？

まあそのうちゆり戻しがくるだろうけどさ、それは性能が最優先課題になる場合くらいしか
出てこないだろうね。

あーうー、いかん。case も標準 SQL だ。
例をあげるなら型キャストとかだったな・・。
鬱出し脳。

お前も人のこと言えんのかこのポストグレス厨房

これ以上荒らすな、バカヤロ。
厨房はお前だ。

PostgreSQL だ MySQL だ Oracle だ とかって、そこまで熱くなれる人たちって、ある意味羨ましいです。
どうしたら、そこまでのめり込めるのでしょうか。
冒頭で書いたようなバカっぽいことでウダウダ言ってる割に、技術的には素人から見て凄そうなので
前から不思議に思ってました。UNIX板のスレなど。
煽りじゃないです。

宗教だねえ、ここまでくると。
作っている人間が熱くなるならわかるけど、作っている本人よりも取り巻きの方が
熱かったりするからねえ。

確かにそこまでのめりこんで見えるものがあるのも事実だと思うけど・・。
# でも最近のメーリングリストの内容の水準の低下を見るとそうでもないか？
　どこでもインストールネタばっかりだし。

あ
私の作ってるサイト（携帯コンテンツ）はかなりのアクセスがあるんで
トランザクションの数が尋常じゃないもんで
それに耐えうるような方法とかご存知でしたら知りたい・・

知ってるけど教えてあげない。コンサルする？

SQL Serverはどうよ
http://www.microsoft.com/Japan/SQL/

なんでPHP版に？
バカチョンって感じかな。。
メンテとかはしやすい

チューニングは意味ない

PostgreSQL って Oracle ほどシステム統計取れない（というか全然取れない）
からチューニングは一苦労だよね。
http://www.linux.or.jp/JF/JFdocs/PostgreSQL-FAQ.html の
3.7, 4.9, 4.10, 4.23 あたりは読んだ？
あとはこの辺かな。
http://www.itboost.co.jp/postgresql/pgsql_tips.php3
あと Vacuum かけないと Index は効果半減。Vacuum と Index の関係については
以下が参考になるかも？
http://www.geocrawler.com/archives/3/6/2000/3/50/3402101/

以上に書いてない事柄で、自分が知っているのはこれくらい。
1 もこれくらいは知っているだろうけど。

・PostgreSQL は遺伝的アルゴリズムを用いてアクセスパスを決定しているが、
　非常に複雑なクエリーの場合、計算量が増えすぎてしまって、そこで余計な
　時間をつぶすことがある。
　$PGDATA/pg_geqo (pg_geqo.sample をコピー) の Generations をぐっと
　減らすと、効率は悪くなるが計算時間も減るので、割と単純なクエリーの
　場合には効果が大きい。

・Join することがないテーブル群がある場合、別々のデータベースに格納し、
　かつそれぞれのデータベースを別のディスク I/O に置く。詳細は Admin Guide の
　Chapter 10 "Disk Management" を参照。
　先のリンクにあるようにテーブルを作って別のディスク上に移動し ln -s
　するのでもよし。

・PostgreSQL のセッションコンテキストの変数を操作することで、アクセス
　パスを手動で最適化することができる（これは今回はじめて知った・・）。
　詳細は Users Guide の 17. Understanding Performace と 19. の sql-set を
　参照。

# 探せば結構出てくるじゃん。

>>37
> 割と単純なクエリーの 場合には効果が大きい
割と複雑な・・・の間違い。

あと、テーブル構成とかはきちんと設計できてるんだよね？

join 操作はコストが大きいから、むやみやたらにテーブルを分けるのはまずい、
場合によっては非正規化も検討するとよいってよく言われる。ただしデータの
整合性を維持するのに Trigger 使うくらいなら join した方が 100 倍いい。

あと index は本当に効果的な場合（つまり WHERE で条件として指定される場合）に
限定して使わないと、レコードを変更・追加するときのコストが大きくなる。

さらにファイル断片化とか起きないように、非常に大きなテーブルは専用の区画を
用意するとか、ときどき export & drop table & import してクリーニング
するとか・・・。

# まあこの辺は PostgreSQL に限らず、常識的な内容ばかりで・・。

つか、何が悲しくて PHP 板に PostgreSQL の話を書かないといけないんだ！？

ということで話題を変更。

PHP スクリプトのデータベースアクセスにも改善の余地はないの？
細かくアクセスするよりまとめてレコード取得したほうが速いってのは
いいだろうけど、コネクションを永続化するとか、日付計算ごときでデータベースを
呼ばないとかはしているよね。

それでもダメなら Zend Optimizer 試してみて、それでもダメなら Zend
Cache 使ってみれば（試用可能）？

>>電動ナナシ
あんたすごいね

>>電動ナナシ
超参考になりました

やっぱちゃんと開発前に時間とっていろいろ考えないとだめですよね。。
でも開発の時間のけつは決まってるし、開発と運用両刀じゃすでに終わってる感じ

インデックス張ってんのにやたらおせーと思ったらそうゆうことでしたか。。。
バキュームね

bakyu-mu kowai mukashi view ga kowaretayo

>>40
全然すごくない。厨房レベルだよ。

>>41
RDBMS はテーブル設計が超重要だからね、事前に時間をとってきちんと設計しないと結構
悲惨なことになるよ。特に忙しいサイトだとね。データ見せられてすぐに第三正規化できる
程度に正規化には習熟しておこう。

『Oracle パフォーマンスチューニング』読んでみるといいよ。Oracle と書いてあるけど、
ベースになる思考や知識は共通。だって RDBMS じゃん。メモリアクセスやディスク
アクセスのパターンがそんなに劇的に変わるはずがない。

Vacuum は index から使われないエントリを削るので、頻繁に削除・変更が起きるなら
必須だね。Rebuild はしてくれないような話も聞くが・・・。explan 使って index が
使われているか確認してみたら？

>>42
Vacuum で何か壊れたって経験はないなあ。自分の面倒見ている範囲では、もう vacuum
回数は 1 万回以上にもなるけど、何か壊れたことはない。ディスク障害とか別の原因が
あったんじゃないの？

電動ナナシ＝いしい
？

今日初めてPostgreSQL+PHP3の組合せに取り組みました。
早速本などを参考にデータベースよりデータを取り出してみようと思ったのですが、
いきなりエラーです。

エラーは
"Unable to connect to PostgreSQL server. FATAL 1: SetUserId :
user' nobody' is not in 'pg_shadow' in /usr/local/apache/...(略)... on
line 10"
みたいに出て来ました。
これはapacheのconfiguファイルで、接続先を設定しなければならないエラーなのでしょ
うか?