ちょっとだけまじめに書いてみる
ちゃんと書くべきことが書かれているので書くことないなーと思ったんですが，時間をあけて気づいたことがあるので，そこも含めてつらつら．
で、そこまでわかっている人間が誰かに伝えるべきことは、pg_pconnect使うと障害対応で人間やめることになるよなどという意味不明な極論ではなくて、例えば「PHPスクリプトを動かすhttpdと画像やCSSを送り出すhttpdは別にしよう」ということだ。 知らずに思考停止しているだけであればまあアレだが（笑）、知っててなおシャレや冗談のつもりで話しているならば誤解を招きすぎである。
冷静に見るとこのようにしか取れないなら残念．こちらの執筆能力に残念って感じか．
そりゃ結論と余談という風に分けましたけどね(笑
ちゃんと書くならこちらが本心に近いです．
チューニングはえてして最初は徹底的にやりづらい．しかし気をつけるべきは「過負荷になってからチューニングで対処」はやけどのモト．
黒ひげ危機一髪的に障害を起こす可能性がより高い状態ということを認識しよう．
そんな状態ならもしあまりノウハウがない人がconfigureしたりソース読んだりしながらDBのチューニングに1人月まるまるかけるならハードウェアリプレースした方がいいかもね．
(snip)
もしくはメモリーを載せられるだけ載せたりHDDをもっと早いものに交換したり，外部にHDDが6本位つめる箱用意してRAID 0+1(パフォーマンス出るならRAID 5とかでもOK)とかで構成してeSATA経由接続にしたり(さすがにFCとか言わない)．postgresql.confの調整はざっくりと程度で．
#長いんで省略していますがいい省略場所がなかった．気が向いた人はリンク先のエントリーを読んでください
まじめにエンジニアリングとして件の記事でいうとこういう感じでしょうか．
件の記事が「PostgreSQLを早くすることだけ」に特化したエントリーのようなので，スコープが違うのは理解したうえで空気を読まずに書いています．
まじめにといいつつ内容書いている時間がないので項目だけ．
そもそもチューニングは改善ではない場合が少なくない
チューニングは運用中に行う場合はとにかく「イマイチな状態をマシ状態に近づける」というのが目の前の目的の場合が多いです．
システムライフサイクルを考えてチューニングが最適なのか，それで巻き取る目標ライフ最フルとかを仮でも決めておかないといけないでしょう．
#それもなしにとに「かくやる」はそれこそ炎上しているとき(苦笑
ハードウェア交換などなどプログラミング以外の要素がでてきますが，インフラ担当者でもいなければこの説得材料を出せる人，あるいはそこに一番近い人はPostgreSQLのメンテナンスをしたりSQLのチューニングをしたりする担当者じゃないでしょうか?
ふつー経理，営業や社長ではこんなのできないですよ(笑
とにもかくにもサイトの特性を知ろう
- せめて「どちらかとゆーとOLAP，OLTP」のどちらかをざっくり知るなどしてみよう
- 時間帯，週の中でのボトルネックを知ろう
- 日付の変わる前後，金曜日は負荷が高いなどの負荷特性
- ビジネスシーンとの兼ね合いの負荷特性(提携先アクションで負荷が変わる場合)
- ディスクIOとCPU負荷の特性の計測をして検討材料にしよう
つまり書いていないことも含め，「せめてシステムの要求を知ろう」ということです．
知るために必要なアクションを考えてください．
大体Web屋の書いていることと + αをやろう
- データベースを取り扱っているなら，PostgreSQL使っているなら当たりじゃハゲみたいなことも少なくないですが，確認を含めてチェックしてみるといいでしょう．
- 時間があるならPostgreSQLのとにかくマニュアル真剣に読んでとりうることができそうな手段をピックアップしまくろう．
- PostgreSQLのメジャーリリース時の記事も読もう
- 自分が使っていないバージョンに関しての記事も「よくなった部分」が書かれているので，裏を返せば「自分の使っているバージョンはそこもダメ，あるいはイマイチなのかもしれない」と取れるポイントかもしれないです．
- マニュアルだけじゃなくメディア情報も探そう．メディアはPostgreSQLの変更履歴より改善点などわかりやすく書き直されている場合があります
- あわよくばサーバーOSについても，ハードウェアについても熟知していきましょう．
- 抜けているかリンク先見ろハゲみたいなポイントがあるのでそれも検討する
- パーティショニングを使おう(比較的少ない工数で仕上げることができて部分INEXより効果が大きいこともあります)．
- 集計テーブルのような目的別テーブルの作成を検討しよう
- 100万件のSELECTなどちゃんとインデックス作ればたいしたことないですけ，たとえば「売り上げを期間絞込みとSUM()で」とかやろうとすると結構つらくなります．
サービス系とは別のサーバーを用意することを検討しよう
営業や経理が集計するための管理画面作成やpgadminなどでのオペレーションはえてしてPostgreSQLにとってちょっとつらいことも少なくないです．
これを対策するために社内に管理用別サーバーを立てることも検討しましょう．レプリケーションはアーカイブログのrsyncなどでどうにかなる場合もあると思いますが，手段も含めて検討してみましょう(レプリケーションじゃない手段もあると思います)．
場合によっては社内においてもかまわないかもしれません．
とりあえずPマークとかITILとかを持っていたり取得をめざしていたり，情報の取り扱いにセンシティブになるべき企業の場合，配置先，運用方針などにも気をつけて現実性を探りましょう．
追記: このエントリーはちゃんと読むべき
もしこのはてダのエントリーを読んでくださっているものの下記を読んでいない方はぜひ読んでください．
SQLや設定ファイルののチューニングの大切さ，実行バイナリーの最適化などの必要性もとてもわかりますが、それで終わっていいのは1タスク渡されてハイ終わり，次はこれやってねってタスクを渡されてこなして終わりって人までです．
個人的にこの人は自称「最近のPostgreSQLは知らない」の人らしいですが，話される内容の本質はいまでも高品質だと思っていますので，現役でPostgreSQL使うならいまからでも上記ブログのフィード読むくらいした方がいいかもね。
とはいっても気になる記事があったときは鵜呑みにせずになるべく話の裏も取りつつ自分の中に取り込みましょう．
