PostGISで1点からの半径検索は、UTMなりに変換してから検索するのがベストプラクティス？

PostGISで半径x m内の地物を検索する場合、latlong（経緯度）で入っているデータだと空間インデックスが効かないので、どうするかと言う問題ですが。
以前、こんな記事を書いて、むりくりlatlong上で「半径x mの円」を内包する（内接ではない）矩形をざっくり計算し、それを空間インデックスと引き当てて、その後distance_sphere（latlongで入っているテーブルに対し、地球を球体近似した上での表面距離を算出する関数）の実行結果と比較する検索方法を紹介しました。
が、これは別にこれが常道というわけではなくて、GIS素人がちょっとずつ独学して、どんなやり方をすればいいかと試行錯誤した結果の産物です。
まあ言うなれば、ISSEIと同レベルのもの。

が、最近ひょんな事からGISを専門に開発しているらしい人のソースを見せてもらう機会があったのですが、そこではTransform関数を使ってlatlongをUTM（ユニバーサル横メルカトル図法。m単位の直角座標系）に変更し、その上でdistance関数を使って範囲検索を行っていました。
具体的には、記憶頼りですが確かこんな感じ（Zone 53N、東経132-138での場合。SRIDは32653。範囲10km検索）。

SELECT * FROM geomtable WHERE ST_Expand(ST_Transform(ST_GeomFromText('POINT(135 35)',4326),32653),10000) && ST_Transform(geom_column, 32653) AND ST_Distance(ST_Transform(geom_column, 32653), ST_Transform(ST_GeomFromText('POINT(135 35)',4326), 32653)) < 10000;

• あれ?Expand使ってたっけ?でも使わないと空間インデックス効かないはずだから、多分これであってるよなあ...。
• いつの間にか、PostGISの関数ってプリフィックス「ST」が付くようになってたのね...。

なるほど、PostgreSQLは関数インデックスも張れるので、ST_Transform(geom_column, 32653)した値について空間インデックスを張るようにしておけば、これで距離半径検索できますね。
多分、単に三平方計算してるだけだと思われるdistance関数の方が、球面距離計算するdistance_sphereより計算早そうだし。
さすが専門家の技。

問題があるとすれば、UTMは経緯度範囲で適用する座標系が異なるので、複数の座標系をまたがるような範囲に対してサービス提供するアプリケーションの場合、その範囲の座標系毎に関数インデックスを張っておかないといけないので、データ挿入・更新の多いアプリケーションだと遅くなるのかも。
また座標系を大きくまたがるような範囲の距離計算は不正確になるので、検索半径も見合った範囲に抑えておく必要がありそうです...まあ、経度6°を上回るような検索は誰もしないと思うけど。

あと、マニュアルを見ると、DWithinというような関数もできているようです。
説明文を読むとこれは空間インデックス使ってくれるそうなので、これまでの「ExpandでMBRの重なりをインデックスチェックしふるいをかけてから、Distanceをチェック」という形じゃなくても、

SELECT * FROM geomtable WHERE ST_DWithin(ST_Transform(ST_GeomFromText('POINT(135 35)',4326),32653), ST_Transform(geom_column, 32653),10000 );

みたいなSQLで、最初のSQLと同じ結果が得られるのかなと。