すこし楽してる最中
Comments (0) ■ ! [[なぜバージョンが上がると速くなるのか|http://blog.postgresql.jp/70]]
■ まあ、PostgreSQLがバージョンを追うたびに遅くならなかったのは、もともと基本的な点を抑えていたから、というのは同意。
■ ただ、パフォーマンス改善について個人的に思うのは、時代の変化というのが実は結構大きな役割を果たしているのではないかと。
■ 某吉岡さんがpgsql-jpだか旧hackers-jp(というのが昔あったのです)で語った「RDBMSのボトルネックはディスクI/OからCPUへと移っていっている」のが印象に残っていて、実はここ数年のリリースによる性能向上はそれを目の当たりにしていると思っているのです。
例えばbufMgrLockを無くす、という今回の目玉も、実際には6.0時代の100MHz,16MBの今となっては玄箱にも劣るようなしょぼいマシンでは殆ど効果が無かったのではなかろうか、と思う。当時、それだけの大接続や大バッファを許容できるマシン自体珍しかったし。
■ でも今ではPostgreSQLは4CPUとか8CPUとかで平然と動かされていて、メモリもたくさん、サイズも巨大化している。だから、そのときに応じてWALのようなI/Oボトルネックの解消から、CPUボトルネック（というかまあロック）の解消に移ることで、新たなチューニングの余地が生まれ、それが今のパフォーマンス向上を支えているように思える。まあ、PostgreSQL自体元々重かったけど。
■ 何が言いたいのかまとめると、PostgreSQLがパフォーマンスを落とさずに機能追加できたのは、最初から高機能だったこと、パフォーマンス要求自体が時代に沿って変化してきたから時代に沿ったチューニング要件が常に残されていた、というところか。
■ ! [[記法重要(1)|http://www.mono-space.net/blog/blosxom.cgi/KOTOBA/051025_kihou.htm]]
書いてあることは非常によく分かる。まあその上で。
■ 微妙なところに突っ込むようだけど、楽譜とソースコードでは情報の質があまりにも違いすぎるので、比べるものとしてアンフェアじゃないかと思う。
■ そして、実は楽譜の方にこそ、書いてない情報というものがたくさんある。良い音楽家というのは、楽譜に書いていないところも読んで音楽を作っていくと言うし。端的に言うと、楽譜は仕様書に過ぎない。そこから（主に指揮者の）多大な努力を払って実装レベルに落とされ、最後には演奏として残るのだけど、結局のところEoMなんかは無理矢理当てはめるとすれば指揮者とかが持っておくべきスキルだし、フィジカル面はもちろん属人的スキルだ。
■ ま、そんな私が個人的に考えることに、ソースコードのあり方はいかに自然か、だと思う。しょぼいソースコードほどごてごてしていてスムーズでなかったり、論点がはっきりしていないので何が言いたいのか分からなかったり（良いソースコードからは、コメントが無くてもこれらがちゃんと読みとれる。だから、メソッドの説明はいるがメソッド内のコメントは普通要らない）、切り張りだらけで論理が破綻していたりする。まあ、こういうのもフィジカル面だと思うんだけど、なかなか身に付かないのも確かだし。
■ プログラマーのためのドリルみたいな本は企画はしたのですが・・・すみません＞誰にだよ
■ ! [[BkS25R|http://home.att.ne.jp/gold/hiro/bks25r/]]
昨日入れたRgrayが使っている理論(？)S25RのBecky!プラグイン版。POPFileと組み合わせて、一部のすり抜けるものも拾ってくれる。動作もまあ重いと言われていても、POPFileよりまし。会社アカウントにはサーバー導入できないので、これを使ってみる。
■ ! [[ いわゆる qsv 系 spam|http://chig.vis.ne.jp/d/200509.html#d29_2]]
NS使ってはじく奴。これも導入済。
