ST_GeomFromTextはどれくらいの高価ですか

Question

ポストギスでは、ST_GeomFromTextコールは非常に高価ですか？ほとんどの場合、私は頻繁に呼び出されるクエリがあります。これは、いくつかの基準に一致する別のポイントに最も近いポイントを見つけようとします。また、そのポイントの特定の距離内にあります。同じST_GeomFromText 2回：

$findNearIDMatchStmt = $postconn->prepare(
    "SELECT  internalid " . 
    "FROM  waypoint " . 
    "WHERE  id = ? AND " . 
    "   category = ? AND ". 
    "   (b.category in (1, 3) OR type like ?) AND ". 
    "   ST_DWithin(point, ST_GeomFromText(?," . SRID . 
    "   ),". SMALL_EPSILON . ") " . 
    "   ORDER BY ST_Distance(point, ST_GeomFromText(?,", SRID . 
    "   )) " . 
    "   LIMIT 1"); 

これを書き直すより良い方法はありますか？

わずかにOT：プレビュー画面で、すべての下線が& # 9 5 ;としてレンダリングされています - そのように表示されないことを希望します。

Answer 1

私はST_GeomFromText()が特に高価ですが、これまではクエリを最適化しましたが、関数を作成し、変数を宣言してST_GeomFromTextの結果を変数に割り当てました。

実行プランを確認する際に、さまざまなパラメータを使用してクエリを実行しようとしましたが、これはクエリのどのビットが時間を費やしているかを明確に示しているはずです。

実行時間の大部分は、ST_DWithin()とST_Distance()の呼び出しで推測されますが、id列とカテゴリ列が索引付けされていない場合は、面白い表スキャンを実行している可能性があります。

Answer 2

@Ubiguch ST_DWithinは空間インデックスを使用しているように見えるので、かなり素早く照会するポイントの数を減らすようです。 order byとlimitなし

navaid=> explain select internalid from waypoint where id != 'KROC' AND ST_DWithin(point,                 ST_GeomFromText('POINT(-77.6723888888889 43.1188611111111)',4326), 0.05) order by st_distance(point, st_geomfromtext('POINT(-77.6723888888889 43.1188611111111)',4326)) limit 1; 
                                                                 QUERY PLAN                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=8.37..8.38 rows=1 width=104) 
    -> Sort (cost=8.37..8.38 rows=1 width=104) 
     Sort Key: (st_distance(point, '0101000020E61000002FFE676B086B53C0847E44D7368F4540'::geometry)) 
     -> Index Scan using waypoint_point_idx on waypoint (cost=0.00..8.36 rows=1 width=104) 
       Index Cond: (point && '0103000020E61000000100000005000000000000C03B6E53C000000060D0884540000000C03B6E53C0000000409D95454000000020D56753C0000000409D95454000000020D56753C000000060D0884540000000C03B6E53C000000060D0884540'::geometry) 
       Filter: (((id)::text <> 'KROC'::text) AND (point && '0103000020E61000000100000005000000000000C03B6E53C000000060D0884540000000C03B6E53C0000000409D95454000000020D56753C0000000409D95454000000020D56753C000000060D0884540000000C03B6E53C000000060D0884540'::geometry) AND ('0101000020E61000002FFE676B086B53C0847E44D7368F4540'::geometry && st_expand(point, 0.05::double precision)) AND (st_distance(point, '0101000020E61000002FFE676B086B53C0847E44D7368F4540'::geometry) < 0.05::double precision)) 
(6 rows) 

典型的なクエリはわずか5〜10ウェイポイントの最大を返しているように、それが見えます。だから、私はおそらく、返されるポイントに適用されるフィルタの追加コストについて心配するべきではありません。