Postgisデータベースクエリの最適化

DTED形式のラスターセットがあり、raster2pgsqlコマンドラインツールを使用してPostGISデータベースにロードします。

各ラスターは単に行に格納され、ridとラスター形式の値によって記述されます。

次に、ポイントの経度と緯度を取得し、このポイントに対応するピクセルの値を返すデータベース関数を作成します。

私が抱えている問題は、データベースがOdroidボードで動作するため、それを行うのにかなりの時間がかかる（3〜4秒）ことです。

私が処理するデータセットは非常に大きい（ラスターは英国全体をカバーしている）ことはわかっていますが、PostgreSQLとPostGISに精通していないため、より高速に処理できると思います。

これは私がこれまでに行ったことです：

SELECT ST_Value(rast, ST_GeomFromText(CONCAT('POINT(', $1, ' ', $2, ')'), 4326))
FROM (
    SELECT * FROM rasters
    WHERE rast && ST_GeomFromText(CONCAT('POINT(', $1, ' ', $2, ')'), 4326)
) x;

$1そして、$2それぞれ長いと緯度です。

— ゼッデッド
ソース

postgisにインポートするときに、ラスターをタイルにカットしましたか？（パラメータ-t幅x高さ）？

— mutolisp 2014年

はい、そうしました。パフォーマンスが少し向上しました。また、データベースがOdroidボード上にあるため、デスクトップPCよりも動作がかなり遅いことも付け加えておきます。どういうわけかラスター処理へのアプローチを変更して、不要な計算を減らすことができるかどうか疑問に思っていました。たとえば、最初はすべてのラスターでST_Value関数を呼び出していましたが、実際に値が含まれている行を探しました。これは最も単純なアプローチでしたが、動作がはるかに遅くなりました。

— zedsdead 2014年

ST_SetSRID(ST_MakePoint($1, $2),4326)文字列連結の代わりに使用すると、十分な反復がある場合に時間を節約できます。

— Scro、2014年

あまり役に立たないようですが、よろしくお願いします。単一のラスターの境界ボックスのみを含むテーブルを作成するときに、別の列を追加することを考えていました。たぶんこの方法で正しいラスターをより速く見つけることができます...また、コーナー座標と経度/緯度のピクセルステップに基づくラスターのピクセル位置の事前計算が役立つかどうか疑問に思っていました...私はそれらを共有することに感謝します:)

— zedsdead

「説明」を使用してボトルネックがどこにあるかを確認することもできます。

— mutolisp 2014年

あなたはこれを試すことができます：

--calculate and store geom point just One time
WITH point_geom AS 
(
    SELECT ST_setsrid(ST_GeomFromText('POINT('|| $1 || ' '|| $2 || ')'), 4326) as geom
)
-- Your subquery is maybe useless , alias "x" isn't used
SELECT ST_Value( rast, point_geom.geom )
FROM rasters
WHERE rast && point_geom.geom;

しかし、実際の問題はラスタークエリです。データセットをタイリングすると、クエリが高速化されます。PostGIS WKT Rasterを使用して、このチュートリアルを試すことができます。

お役に立てれば幸いです。

— 弁野
ソース