Question

在我的PostgreSQL 9.3数据库中，我有一个名为location的表，其中包含用于存储coordinate几何的POINT列。这些点是使用SRID 4326创建的。在某些情况下，我们ST_Transform这些坐标到SRID 900913，使用米的距离过滤它们。

例如，要使用ST_WDithin查找坐标在给定坐标10000米范围内的所有位置，查询将如下所示：

SELECT *
FROM LOCATION 
WHERE ST_DWithin(ST_Transform(location.coordinate, 900913), ST_Transform(ST_GeomFromText('POINT(-74.005941 40.712784)', 4326), 900913), 10000)
ORDER BY ST_Distance_Sphere(location.coordinate, ST_GeomFromText('POINT(-74.005941 40.712784)', 4326))
LIMIT 100

此语句的查询计划如下所示：

Limit  (cost=19207.98..19208.23 rows=100 width=36)
  ->  Sort  (cost=19207.98..19209.81 rows=729 width=36)
        Sort Key: (_st_distance(geography(coordinate), '0101000020E6100000282D5C56618052C0588E90813C5B4440'::geography, 0::double precision, false))
        ->  Seq Scan on location  (cost=0.00..19180.12 rows=729 width=36)
              Filter: ((st_transform(coordinate, 900913) && '010300002031BF0D000100000005000000D42FBDEAFB765FC187C3AD4ED1EB5241D42FBDEAFB765FC187C3AD4E59FF5241D42FBDEA73635FC187C3AD4E59FF5241D42FBDEA73635FC187C3AD4ED1EB5241D42FBDEAFB765FC187C3AD4ED1EB5241'::geometry) AND ('010100002031BF0D00D42FBDEA376D5FC187C3AD4E95F55241'::geometry && st_expand(st_transform(coordinate, 900913), 10000::double precision)) AND _st_dwithin(st_transform(coordinate, 900913), '010100002031BF0D00D42FBDEA376D5FC187C3AD4E95F55241'::geometry, 10000::double precision))

这很有效，但速度很慢。所涉及的所有坐标都转换为SRID 900913，以便能够以米为单位工作。通过测试，我发现删除ST_Transform会大大加快此查询速度。

我还尝试使用ST_Buffer创建一个圆形POLYGON，然后测试以查看location.coordinate是否与此多边形相交。为此，我ST_Transform输入坐标为SRID 900913，使用ST_Buffer绘制半径为米的圆，然后ST_Transform该多边形为SRID 4326，以与我的位置表中的坐标进行比较。查询如下所示：

SELECT *
FROM LOCATION 
WHERE location.coordinate && ST_Transform(ST_Buffer(ST_Transform(ST_GeomFromText('POINT(-74.005941 40.712784)', 4326), 900913), 10000), 4326))
ORDER BY ST_Distance_Sphere(location.coordinate, ST_GeomFromText('POINT(-74.005941 40.712784)', 4326))
LIMIT 100

在我的测试中，第二个查询的运行速度远远快于第一个查询。它甚至比使用ST_DWithin减去ST_Transform的查询版本运行得快一点。从我读过的所有内容来看，似乎ST_DWithin应该是执行此类搜索的最快方式。这个问题的答案表明我应该能够创建一个转换为不同SRID的坐标索引：PosgtreSQL Optimize Query with st_transform, st_makepoint, and st_contains

我试图通过运行：

CREATE INDEX idx_location_coordinate_900913
 ON LOCATION
 USING gist
 (ST_Transform(coordinate, 900913))
 WHERE coordinate IS NOT NULL;

创建此索引后，我发现在运行原始查询时没有速度提升。我发现很奇怪，这个命令很快就成功完成，重建这个索引很快就发生了。位置表中有成千上万的行，所以我想创建这个索引将是一个耗时的过程。我是否错误地创建了它？

在转换点数时，我能做些什么来加速ST_DWithin？我的方法在这里有一个重大缺陷吗？

编辑：我正在为上面的初始查询添加执行计划。

Answer 1

我建议在PostgreSQL中创建一个函数来处理从米到十度的转换。通过这样做，您可以避免转换每一行，而ST_DWithin函数正在本机投影中工作。

您想要仔细检查数学，我建议将结果与使用ST_Transform进行比较，但我很确定这很接近。我使用的功能通常使用英里而不是米，但我快速尝试添加米的转换。

在函数中，值3960是对地球直径的估计，而1609.34处理从英里到米的变化。我不保证它与ST_Transform一样精确或准确，但它应该更好地表现，因为它不必转换每一行。

CREATE FUNCTION meters_to_decimal_degrees(meters double precision)
RETURNS double precision AS
$BODY$
    SELECT (($1 * 180 * 1609.34) / ( 3960 * pi() ) ) AS decimal_degrees
$BODY$
LANGUAGE sql IMMUTABLE SECURITY DEFINER
;


ALTER FUNCTION public.meters_to_decimal_degrees(double precision) SET search_path=public, pg_temp;

有了这个，你的查询可以改为：

SELECT *
    FROM LOCATION 
    WHERE ST_DWithin(location.coordinate, ST_GeomFromText('POINT(-74.005941 40.712784)', 4326), meters_to_decimal_degrees(10000))
    ORDER BY ST_Distance_Sphere(location.coordinate, ST_GeomFromText('POINT(-74.005941 40.712784)', 4326))
    LIMIT 100

希望这有帮助。

ST_DWithin优化多个SRID

1 个答案: