ラスターデータベースのクエリを高速化する方法は？

私はこれらの列を持つpostgresql / postgisにラスターデータベースを持っています：

（ID、rast、data_of_data）。

「ラスト」は、WKT形式のラスターファイルがある列です。WGS84システム（30.424、-1.66）および2002-01-09のポイントのDN値を検索するクエリの例は次のとおりです。

SELECT 
     st_value(rast,(st_GeomFromText('POINT(30.424 -1.66)', 4326))) as val
FROM 
     my_table
WHERE
     date_of_data='2002-01-09'

これらの種類のクエリを高速化する方法（空間インデックスなど）はありますか？

これは刺激的な質問です！クエリするラスターの大きさは？WKTRasterはBLOBとしてデータベースに保存されます。特定のポイントで値を見つけるために、既知の（x_0、y_0）コーナー座標から行/列インデックス（i、j）が（dx、dy）ステップと回転を使用して計算されます。（i、j）が既知の場合、ST_Value（）関数は正しいバイトオフセットで実際のデータにアクセスできます。

これは、ポイントのクエリに応答するときに、DBが平均でデータブロブの少なくとも半分を読み取る必要があることを意味します（実装に応じて、常にすべてのデータを実際に読み取ることができます）。したがって、データBLOBが大きくなりすぎると、WKTRasterのパフォーマンスが低下すると思います。データセットをタイリングすると、クエリが高速化されます。このチュートリアルで SRTMデータ（6000x6000ピクセルチャンクで受信）の処理方法をご覧ください。彼らは実際にデータを本当に小さな50x50ピクセルに並べます。これは、私の推測が真実からそれほど遠くないかもしれないという明確なヒントです。

ラスターデータを空間的にインデックス付けすると、おそらくバウンディングボックスのみがインデックス付けされますが、これは問題の本当の助けにはなりません。

私が見つけた2つの側面は、PostGISラスター計算を高速化し、ラスターで整数値を使用することと、可能な場合はマルチバンドラスターを使用することでした。この場合、DN値を整数として保存できますか（まだ行われていない場合）。

もう1つの考えは（ここでは関連性があるとは思いませんが）、マルチバンドラスタを使用することです。たとえば、データの月ごとのスライスを表示している場合、各月はラスターレイヤーである可能性があります。その後、レイヤー化されたラスターをクエリすることにより、異なるタイムスライスでポイントの複数の値を取得できます。このアプローチは、個別のラスタをクエリするよりもはるかに高速であることがわかりました。

最後に、データをロードすると、TILE_SIZEの-tフラグがあります。使用しているタイルサイズがクエリに適しているかどうかを調べることができます。

データの分布に応じて、date_of_data列のインデックスを作成するだけで非常に優れた高速化を実現できます。

EXPLAIN ANALYZE構文を使用して、インデックスが使用されているかどうかを判断できます。