非常多的 SQL UNION SELECT 语句超过了 max_stack_depth

Question

我正在尝试为一组给定多边形中的一个或多个内的所有唯一点开发基于空间的 SQL 查询。我在具有 6 个 vCPU 和 16 GB RAM 的云 VPS 上使用 PostGIS。有问题的空间测试是 WHERE 子句上的 ST_Contains。多边形集包含大约 40,000 个独特的几何图形，它们约束着 370 万个特征点数据集。

我的问题是，当我创建一个包含超过 13,000 个多边形的查询（因此有 13,000 个 SELECT 语句）时，PostGIS 服务器会以ERROR: stack depth limit exceeded" 进行响应 HINT: Increase the configuration parameter "max_stack_depth"。

我想知道为什么以及是否可以解决它。

这是优化练习的一部分。我已经将多边形几何作为单独的 SELECT 检索以形成所需的 SQL 查询。我想执行将多边形集测试为单个 SQL 语句的查询。到目前为止，我一直在为每个多边形构建一个 SELECT 子查询，然后将每个 UNION 一起作为起点。编译后，仅使用 13,000 个多边形的查询约为 28,000,000 个字符，我认为这远低于 PostGIS SQL 语句的限制。

我尝试了较小的尺寸，发现正常性能达到了近似极限。我之前已经达到了这个限制，但是在听取了错误消息的建议后，我将“max_stack_depth”增加到了大约“ulimit -s”返回的大小。以我目前的理解，此 SQL 语句不是任何类型的递归函数，我认为这会导致超出堆栈深度。

此外，从我对堆栈与堆内存的阅读中，我无法理解为什么此查询会使堆栈过载，因为大多数所需的存储数据最终都应该在堆中。我还希望查询在收集结果时按顺序执行，但似乎 PostGIS 可能首先运行所有 SELECT 子语句，然后计算结果。

我选择不尝试将单个多边形几何图形合并为一个多边形，因为它们覆盖了地理上非常多样化的区域（即不聚集成一个简单的块），我认为这会大大降低空间索引的好处。

我当前的工作 SQL 脚本遵循模式（修剪以适应这篇文章）：

SELECT * FROM point_table WHERE ST_Contains("poly1_geom_str", pt_geom_col)
UNION
SELECT * FROM point_table WHERE ST_Contains("poly2_geom_str", pt_geom_col)
UNION
....
SELECT * FROM point_table WHERE ST_Contains("polyN_geom_str", pt_geom_col);

我构造这条 SQL 语句的策略是不是不太可能解决？有没有我可以尝试的替代策略来避免递归问题？

Answer 1

您可以尝试查询的这种变体。它从不同的多边形字符串创建一个临时表，然后基于ST_Contains 执行连接：

SELECT  DISTINCT point_table.* 
FROM    point_table 
JOIN    (values ("poly1_geom_str"), 
                ("poly2_geom_str")
        ) as polys(poly_str)
     ON ST_Contains(poly_str, pt_geom_col)

当然，如果这些几何图形实际上来自现有表，那么只需加入该表即可：

SELECT  DISTINCT point_table.* 
FROM    point_table 
JOIN    polys
     ON ST_Contains(poly_str, pt_geom_col)

Answer 2

你考虑过or吗？

SELECT *
FROM point_table
WHERE ST_Contains("poly1_geom_str", pt_geom_col) OR
      ST_Contains("poly2_geom_str", pt_geom_col) OR
      ....
      ST_Contains("polyN_geom_str", pt_geom_col);