Create index some_name_idx on public."Locations" using gist("MyCoord")
のようなテーブルでそれ
SELECT "Locations"."Name",
FROM public."Locations"
WHERE
"Locations"."Enabled" = TRUE
AND ST_DWithin(
"Locations"."MyCoord"::geography,
ST_SetSRID(ST_MakePoint(<Given Long>, <Given Lat>),4326)::geography,
"Locations"."Radius");
ため、この作業クエリを持っている。しかし、あなたがバグを持っている - そのような機能ST_DWithin(ジオメトリーは、ありません地理学、数値) - メートル単位の半径がある場合はどちらの場合も地理学を使用するため、変換は必要ありません(インデックスの場合も同様)
EDIT:
心配しないでください - それは動作します、私はそれを確認...証拠として、私は、インデックスとosm2pgsqlによって作成されたテーブルplanet_osm_pointを持っている:
CREATE INDEX planet_osm_point_index
ON planet_osm_point
USING gist
(way);
そして、私はあなたのようなクエリを実行している:
explain select *
from planet_osm_point
where st_dwithin(way,ST_geomfromtext('POINT(2219360.7 6457010.96)'),300)
出力がhereです。 空間インデックスが使用中であることを確認してください...
これは地理的にもコピー&ペーストエラーです。しかし、インデックス内で半径が使用されていない場合は、どのようにMyCoordのインデックスが検索のスピードアップにつながりますか(AFAIKでは、検索を高速化するために少なくとも境界ボックスが必要です)。 – Fionn
私があなたのクエリで見る微妙な違いは、静的な距離をチェックすることですが、私のクエリでは距離と1つの座標がクエリテーブルにあります。したがって、クエリには1つの可変要素だけがあり、鉱山には2つの要素があります。 – Fionn
あなたはそれをチェックしましたか?この要素は、インデックスが作成された後に思い出された変数でもあります。違いはありません。あなたが見るように、インデックスの定義には300はありません... – Jendrusk