テストのタイミング
EXPLAIN
には、行ごとの個々の関数の評価は表示されません。 出力。
EXPLAIN ANALYZE
でテストする 全体的な有効性を比較するために実際のクエリ時間を取得します。キャッシュアーティファクトを除外するには、数回実行します。このような単純なクエリの場合、次のコマンドを使用すると、ランタイム全体でより信頼性の高い数値が得られます。
EXPLAIN (ANALYZE, TIMING OFF) SELECT ...
Postgresが必要9.2+ 。 ドキュメントごと :
繰り返しの評価を防ぐ
通常、サブクエリの式は一度評価されます。 。しかし、Postgresは、それがより速くなると考える場合、些細なサブクエリを折りたたむことができます。
最適化の障壁を導入するには、 CTE<を使用できます。 / strong>
サブクエリの代わりに。この保証 PostgresがST_SnapToGrid(geom, 50)
を計算する 1回のみ:
WITH cte AS (
SELECT ST_SnapToGrid(geom, 50) AS geom1
FROM points
)
SELECT COUNT(*) AS n
, ST_X(geom1) AS x
, ST_Y(geom1) AS y
FROM cte
GROUP BY geom1; -- see below
ただし、これはおそらく遅い CTEのオーバーヘッドが大きいため、サブクエリよりも。関数呼び出しはおそらく非常に安価です。一般に、Postgresはクエリプランを最適化する方法をよく知っています。よく知っている場合にのみ、このような最適化バリアを導入してください。
簡素化
サブクエリ/CTEで計算されたポイントの名前をgeom1
に変更しました 元のgeom
とは異なることを明確にするため 。これは、より重要なを明確にするのに役立ちます ここにあるもの:
GROUP BY geom1
代わりに:
GROUP BY x, y
これは明らかに安価であり、関数呼び出しが繰り返されるかどうかに影響を与える可能性があります。したがって、これはおそらく最速です:
SELECT COUNT(*) AS n
, ST_X(ST_SnapToGrid(geom, 50)) AS x
, ST_y(ST_SnapToGrid(geom, 50)) AS y
FROM points
GROUP BY ST_SnapToGrid(geom, 50); -- same here!
または多分これ:
SELECT COUNT(*) AS n
, ST_X(geom1) AS x
, ST_y(geom1) AS y
FROM (
SELECT ST_SnapToGrid(geom, 50) AS geom1
FROM points
) AS tmp
GROUP BY geom1;
EXPLAIN ANALYZE
で3つすべてをテストします またはEXPLAIN (ANALYZE, TIMING OFF)
自分の目で確かめてください。テスト>>推測。