Question

我在优化一些posgresql查询方面遇到了一些麻烦。例如，这个接缝是最慢的：

select  st_astext(geom), 'all' as type
from (
   select ST_Simplify(ST_Intersection(ST_MakePolygon(ST_GeomFromText(? ,4326)), st_transform(way, 4326)), ?) as geom
   from planet_osm_polygon 
   where (sT_Intersects(ST_MakePolygon(ST_GeomFromText(?,4326)), st_transform(way,4326))=true)
   and   ('natural' IN ('water', 'pond') OR waterway IN ('basin', 'canal', 'mill_pond', 'pond', 'riverbank', 'stream'))
) AS subquery";

我做的第一件事就是编辑conf文件并更改缓冲区大小，花费的总时间减少了几个百分点。

我接下来要做的是从现有表创建新表并将多个多边形分成多边形。这大部分的查询加速了70-90％。但是，最慢的3个查询速度并没有超过几个百分点。

通过使用EXPLAIN和ANALYZE检查搜索，我意识到不使用索引。使用的是seqscan即使我禁用它。据我所知，这意味着我应该制作一个新的索引。

在表planet_osm_polygon中，我有两个索引：

CREATE INDEX planet_osm_polygon_index_poly
  ON planet_osm_polygon_poly
  USING gist (way);

CREATE INDEX planet_osm_polygon_poly_pkey
  ON planet_osm_polygon_poly
  USING btree (osm_id);

任何想法如何加快此查询以及为什么不使用索引？

这对我来说很新，如果我写的东西没有意义，那就忽略它吧。）

Answer 1

索引可能与WHERE部分中的ST_Intersects一起使用，除非它们不是因为对数据使用了函数，即st_transform(way,4326)。你的选择是避免这个功能（在原生投影中执行一个interesction查询，这将产生不同的答案），或者使用该函数添加一个索引（虽然我不是100％肯定这可以用于ST_Intersects）。 / p>

最后，两点。 SELECT 'natural' IN ('water', 'pond');总是假的。并且SELECT true=true为真，因此任何布尔运算符（如ST_Intersects(g1, g2)=true）在逻辑上都是有效的，但在美学上是多余的。只需使用ST_Intersects(g1, g2)而不使用“等于真”部分。

Postgresql查询优化索引未使用

1 个答案: