アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
適切なチューニング (スコア:1)
デフォでパフォーマンスが出ないとか、
特種な設定やらテーブル組しないとダメ
というのを言ってしまっている様に思える。
チューニングが必要ならStartsPackみたいなのを同梱しちゃうとか出来ないかな？
Re:適切なチューニング (スコア:3, すばらしい洞察)
当たり前、設計・構築前からチューニング前提という感じなんですが。
チューニングしなくても十分パフォーマンスが出るようなデータ量や構造ならば
どれ使ってもいいんじゃないですか、好きなのどうぞと回答することにしてます。
まあ、サーキットを走らせようという車とそこらの生活道路を走る車を同列に
扱うこと自体意味がないのと一緒ですから。こういうDBパフォーマンスモノの
記事は専門でやっているのでなければ、そういうもんかと思っておけばいいん
ではないでしょうか。
DBの自律チューニングが発達すればいいという発想もありですが。
Re:適切なチューニング (スコア:1)
>当たり前、設計・構築前からチューニング前提という感じなんですが。
それは、わかるりますが...このトピックの
>以前のベンチマーク(や印象論の類)との違いは、PostgreSQLに適切なチューニングを施したかどうかにあるようだ。
ということは、一般に行われるであろうベンチマークに耐えないレベル
を提供しているのか、そもそも「適切な」チューニングとは、その
ベンチマークにのみ特化したチューニングなのか？という意味で疑義を
提示したわけなんですけどね。
＞DBの自律チューニングが発達すればいいとい
Re:適切なチューニング (スコア:3, 興味深い)
>以前の、原始的すぎることしないとPostgreSQLはだめないかな？
えーと、もしかして他のDBはしなくてもよいと思ってますか？
暇なときに近くにいるDB技術者(大規模な設計・構築をこなせる人)を捕まえて
話を聞いてみるといいですよ。
結局、今までは海外ではMySQLほど使われないPostgreSQLをちゃんと評価
しようという試みがなかったが、今回やってみたら案外いい感じじゃん？
というのがブログのお話なんではないかと。
#1年ほど前に5種のDB製品評価を手伝ったことがありますが、
#一番作業工数がかかったのは各DBでいい値が出るようにチューニング
#することでした。そんなもんですよ。
Re:適切なチューニング (スコア:0, 荒らし)
ええ。少なくともOracleでGCCのパラメータはいじった記憶がないので....
＞今回やってみたら案外いい感じじゃん？
あ、それは納得しているんですよ。
でも、それが「適切なチューニング」を以前はしていないというのが謎なわけね。
でもって、GCCのパラメータとか言っているのは..と思うわけですよ。
Re:適切なチューニング (スコア:0)
＞
＞ええ。少なくともOracleでGCCのパラメータはいじった記憶がないので....
ヒント：PostgreSQLはソース配布、Oracleはバイナリ配布。
Re:適切なチューニング (スコア:0, 荒らし)
ええ、君は馬鹿なんだろうね。
適切なコンパイルできる環境が提供されていないということなんだろうね。
まわりがガラクタだと、中心部分が優秀だったとしても、無駄なだけだと思うよ。
Re:適切なチューニング (スコア:1)
実際、PostgreSQLはそういう状況だったわけだ。
ソース配布であるにもかかわらず、適切なチューンを施したコンパイルも出来ないmakeファイルを配布していたわけだ。
チューニングパラメータにコンパイル最適レベルを探さないとダメとしたら、それはもはやDBチューニングではないだろ？という当然に、答えられないわけですから...
そこらへんを考えて配布すると、本領が発揮できてよいと思うのですけど、/.Jにはそういう意見にはマイナスなんでしょうね。