座標によるクエリに時間がかかりすぎる-最適化するオプション？

Rツリーを使用する空間インデックス（基本的には、スペースをボックスに分割することによって動作する2次元インデックス）を使用する方がはるかに優れており、2つの別々の緯度での比較よりもはるかに優れています。、この種のクエリのlon値。ただし、最初にジオメトリタイプを作成する必要があります。次に、現在使用している個別の緯度/孤立電子対の代わりに、インデックスを作成してクエリで使用します。

以下では、ジオメトリタイプを作成してデータを入力し、それにインデックスを追加して、それがポイントであり、EPSG：4326として知られる緯度/経度であることを確認します。

alter table event add column geom geometry(POINT, 4326);
update event set geom=ST_SetSrid(ST_MakePoint(lon, lat), 4326);
create index ix_spatial_event_geom on event using gist(geom);

次に、次のクエリを実行して、空間交差を使用するイベントを取得できます。これにより、空間インデックスが利用されます。

Select * from events where ST_Intersects(ST_SetSRID(ST_MakeBox2D(ST_MakePoint(swLon, swLat), 
    ST_MakePoint(neLon, neLat)),4326), geom) 
order by relevancy desc limit 100;

ST_MakeBOX2Dを使用して、境界ボックスの対角線の角にある2セットのポイントを使用して交差点の境界ボックスを作成します。これにより、SWとNE、またはNWとSEのペアが両方とも機能します。

これについてexplainを実行すると、空間インデックスが含まれていることがわかります。これは、2つのBツリーではなく、空間検索用に最適化された1つのインデックスのみをヒットするため、lon列とlat列の2つの個別のインデックスよりもはるかに優れたパフォーマンスを発揮します。これは別の方法であり、間接的な場合を除いて、元の質問には答えられないことを理解しています。

編集： Mike Tは、4326のバウンディングボックス検索では、SRIDが無視されるため、ジオメトリデータ型と&&演算子を使用する方が適切で迅速であるという非常に良い点を指摘しています。たとえば、

 where ST_MakeBox2D(ST_MakePoint(swLon, swLat), ST_MakePoint(neLon, neLat)) && geom