ErogameScape －エロゲー批評空間

事故らないために普段守っているターミナルの運用ポリシ（Mac + iTerm2） | TechRachoを読んで、.ssh/configにProxyCommandを書くと、exitしたときに踏み台サーバーに戻るのではなくて、そのままセッションが切れるように出来るということを知りました。

自分は仕事でNW機器の監視と故障対応をしているので踏み台NW機器というのでしょうか…を経由して、作業をすることがたまにあるのですが、いくら気をつけていても、いくら2人で作業をしていても、やっちゃうときはやっちゃいます。

やっちゃうのは、ド定番で、知らない間に(知らなくはないのですが…自分的には知らない間に…)セッションが切れるか、切ったりして、本来踏み台の先のNW機器にいれるコマンドを、踏み台のNW機器に入れてしまうことです。

踏み台になるのは、二重構成になっているNW機器の逆の系のNW機器なことが多いのですが、踏み台を経由して故障したNW機器にログインして、試しにリセットでもしてみるかーと思ってリセットするコマンドを、踏み台のNW機器で実行してしまって(以下略

NW機器にもProxyCommand的な何かが欲しい…そう思いました。

※ちなみに、以下略の後、私は叫びました。

今まですごい勘違いをしていたのでメモします。

複合インデックスについてのドキュメントは以下がいいかなと思います。

※公式マニュアルは、Verが低いものは分かりやす…くもない気がしますが、まあ分かるのですが、9.3のマニュアルは、これから書くことがいまいち分からない気がします。

さて、ErogameScapeではuserreviewテーブル、ユーザーさんがゲームにつける得点や感想を格納するテーブルで複合インデックスが設定されています。

ap2=# \d userreview
(中略)
インデックス:
    "userreview_pkey" PRIMARY KEY, btree (game, uid)
(中略)

userreviewテーブルはmyuserテーブルとgamelistテーブルの主キーの2つをPRIMARY KEYとして持つテーブルです。PRIMARY KEYには自動的にINDEXが設定されます。PRIMARY KEYがgameとuidなので複合インデックスが設定されます。

インデックス「userreview_pkey」は、例えば、SELECT * FROM game = 1 AND uid = 'ap2';というSQLの場合に活用されます。
また、SELECT * FROM userreview WHERE game = 1;というSQLの場合にも活用されます。
しかしSELECT * FROM userreview WHERE uid = 'ap2';というSQLの場合、インデックス「userreview_pkey」は効かないので、別にINDEXを設定する必要があります。
例えば、
CREATE INDEX userreview_uid_index ON userreview(uid);
な感じです。

私がずっと勘違いしていたのは、
CREATE INDEX userreview_game_index ON userreview(game);
が必要ではなかった…ということです。
上記INDEXを設定しなくても、
"userreview_pkey" PRIMARY KEY, btree (game, uid)
という複合インデックスがあると、SELECT * FROM userreview WHERE game = 1;の場合にもINDEXが使われます。

10年くらい前からずっと勘違いしていて、無駄なINDEXを設定していました…
無駄なINDEXを設定するとINSERTとDELETE時(かな?)にオーバーヘッドになるのでよろしくないです…

ErogameScape －エロゲー批評空間－ Blog

2014年04月

踏み台経由で作業をする場合の注意点と対策

PostgreSQLの複合インデックスについて