在另一个查询的WHERE子句中使用一个PostGIS SQL查询的结果

我正在构建一个地图应用程序，它将GPS轨迹作为坐标列表存储在一个名为“基点”的表格中

我有一个web应用程序，它使用传单来显示这些曲目。当我移动地图时，我使用当前视图的边界对我的后端进行AJAX调用

我想返回地图边界内的一组简化点

首先，我使用了这个非常有效的查询：

SELECT ST_AsGeoJSON(
               ST_Simplify(
                       ST_MakeLine(ARRAY(SELECT geom
                                         FROM base_point
                                         WHERE track_id = %s
                                           AND geom @
                                               ST_MakeEnvelope(
                                                       %s, %s, %s, %s, %s)
                                         ORDER BY time)),
                       %s
                   )
           );

问题是，在轨迹存在并进入视口的某些缩放级别上，我得到了轨迹的子集，因为某些部分被geom@ST_MakeEnvelope剪切。我想在视口中找到“最小”和“最大”轨迹点，并使用它们检索所有的点，然后使用ST_SimplifyST_MakeLine

我正在尝试下面的SQL表达式，但它不起作用

WITH bounds as (SELECT MIN(id) as min, MAX(id) as max
                FROM base_point
                WHERE track_id = %s
                  AND geom @ ST_MakeEnvelope(%s, %s, %s, %s, %s))
SELECT ST_AsGeoJSON(ST_Simplify(ST_MakeLine(ARRAY(
        SELECT geom 
        FROM base_point, bounds 
        WHERE track_id = %s 
            AND id < bounds.max 
          AND id > bounds.min ORDER BY time
    )),
%s)); 

我以前编辑过这个，现在查询可以运行了，但是速度非常慢

以下是解释/分析输出：

Result  (cost=8.95..34.46 rows=1 width=32) (actual time=59806.894..59806.896 rows=1 loops=1)
  InitPlan 1 (returns $2)
    ->  Sort  (cost=8.95..8.95 rows=1 width=40) (actual time=59803.755..59804.242 rows=14001 loops=1)
"          Sort Key: base_point.""time"""
          Sort Method: quicksort  Memory: 1478kB
          ->  Nested Loop  (cost=4.88..8.94 rows=1 width=40) (actual time=13.074..59799.753 rows=14001 loops=1)
                Join Filter: ((base_point.id < (max(base_point_1.id))) AND (base_point.id > (min(base_point_1.id))))
                Rows Removed by Join Filter: 523
                ->  Index Scan using base_point_track_id_b527d95c on base_point  (cost=0.43..4.45 rows=1 width=44) (actual time=0.031..2.440 rows=14524 loops=1)
                      Index Cond: (track_id = 40)
                ->  Aggregate  (cost=4.46..4.46 rows=1 width=8) (actual time=4.117..4.117 rows=1 loops=14524)
                      ->  Index Scan using base_point_track_id_b527d95c on base_point base_point_1  (cost=0.43..4.45 rows=1 width=4) (actual time=0.005..3.477 rows=14003 loops=14524)
                            Index Cond: (track_id = 40)
                            Filter: (geom @ '0103000020E61000000100000005000000C3F5285C8FF256C08FC2F5285C4F4340C3F5285C8FF256C07B14AE47E15A4440A4703D0AD73355C07B14AE47E15A4440A4703D0AD73355C08FC2F5285C4F4340C3F5285C8FF256C08FC2F5285C4F4340'::geometry)
                            Rows Removed by Filter: 521
Planning Time: 0.294 ms
Execution Time: 59807.087 ms

---

如果我分开查询并硬编码ID以进行比较，查询将在15毫秒内运行。

为from子句添加边界。 选择几何图形 从基点开始，边界

---

在那里……

我找到了答案。进行连接要快得多

WITH bounds as (SELECT MIN(id) as min, MAX(id) as max
                FROM base_point
                WHERE track_id = %s
                  AND geom @ ST_MakeEnvelope(%s, %s, %s, %s, %s))
SELECT ST_AsGeoJSON(ST_Simplify(ST_MakeLine(ARRAY(
        SELECT geom 
        FROM base_point
        INNER JOIN bounds ON
            id < bounds.max 
          AND id > bounds.min ORDER BY time
    )),
%s)); 

---

如果有人能解释原因，我将不胜感激

那似乎太容易了！今天晚些时候我会试试。这确实有效，但速度很慢。我已经更新了这个问题。我不认为CTE的结果真的被缓存了，但我以前从未读过解释/分析输出，所以这有点神秘。也许明天我睡了以后会更有意义。