ST_Intersectionスロークエリ

2つのレイヤー間の交差を実行しようとしています。

1. 一部の道路を表すポリラインレイヤー（最大5500行）
2. さまざまなポイント（約47,000行）の周りの不規則な形状のバッファーを表すポリゴンレイヤー

最終的に、私がやろうとしているのは、ポリラインをこれらの多くの（場合によってはオーバーラップする）バッファーにクリップし、各バッファーに含まれる道路の全長を合計することです。

問題は、物事がゆっくり実行されていることです。これにどれくらい時間がかかるかはわかりませんが、34時間を超えるとクエリを中止しました。私は誰かが私のSQLクエリで間違いを犯した場所を指摘するか、これを行うより良い方法を教えてくれることを望んでいます。

CREATE TABLE clip_roads AS

SELECT 
  ST_Intersection(b.the_geom, z.the_geom) AS clip_geom,
  b.*

FROM 
  public."roads" b, 
  public."buffer1KM" z

WHERE ST_Intersects(b.the_geom, z.the_geom);


CREATE INDEX "clip_roads_clip_geom_gist"
  ON "clip_roads"
  USING gist
  (clip_geom);



CREATE TABLE buffer1km_join AS

SELECT
  z.name, z.the_geom,
  sum(ST_Length(b.clip_geom)) AS sum_length_m

FROM
  public."clip_roads" b,
  public."buffer1KM" z

WHERE
  ST_Contains(z.the_geom, b.the_geom)

GROUP BY z.name, z.the_geom;

元のroadsテーブル用にGiSTインデックスを作成しましたが、2番目のテーブル作成を行う前に（安全のために）インデックスを作成します。

PGAdmin IIIのクエリプランは次のようになりますが、解釈するスキルがあまりないのではないかと思います。

"Nested Loop  (cost=0.00..29169.98 rows=35129 width=49364)"
"  Output: st_intersection(b.the_geom, z.the_geom), b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  Join Filter: _st_intersects(b.the_geom, z.the_geom)"
"  ->  Seq Scan on public."roads" b  (cost=0.00..306.72 rows=5472 width=918)"
"        Output: b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  ->  Index Scan using "buffer1KM_index_the_geom" on public."buffer1KM" z  (cost=0.00..3.41 rows=1 width=48446)"
"        Output: z.gid, z.objectid, z.facilityid, z.name, z.frombreak, z.tobreak, z.postal_cod, z.pc_area, z.ct_id, z.da_id, z.taz_id, z.edge_poly, z.cchs_0708, z.tts_06, z.the_geom"
"        Index Cond: (b.the_geom && z.the_geom)"

この操作は数日間実行する運命にあるだけですか？現在、これをWindows用のPostGISで実行していますが、理論的にはAmazon EC2に配置することで、問題にさらにハードウェアを投げることができます。ただし、クエリは一度に1つのコアのみを使用していることがわかります（さらに使用する方法はありますか？）。

ピーター、

どのバージョンのPostGIS、GEOS、およびPostgreSQLを使用していますか？
する

SELECT postgis_full_version（）、version（）;

1.4から1.5とGEOS 3.2+の間では、この種の機能について多くの機能強化が行われています。

また、ポリゴンにはいくつの頂点がありますか？

やる

SELECT Max（ST_NPoints（the_geom））As maxp FROM sometable;

最悪のシナリオを把握するため。このような低速は、多くの場合、最終的にきめが粗すぎるジオメトリによって引き起こされます。その場合、最初に単純化することができます。

また、postgresql.confファイルを最適化しましたか？

役立つスタック交換の答え：https : //stackoverflow.com/questions/1162206/why-is-postgresql-so-slow-on-windows

postgresのチューニング：http : //wiki.postgresql.org/wiki/Performance_Optimization

経験から推奨するVACUUM ANALYZE

恥知らずのプラグ:)私たちの本の第8章と第9章を読むのに役立つかもしれません。プレスを熱くするだけです。これらの章では、こうした種類の質問の多くを取り上げています。

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09

空間クエリを最適化する2つのヒントを参照してください。彼らは私にとって非常にうまく機能します。 http://kb.zillionics.com/optimize-spatial-query/