使用GIST索引（<->函数）的Postgis 2.0中的最近邻居问题

我正在尝试使用Postgis 2.0新功能<->（几何距离质心），以便为我的表格（cosn1）的每一行计算到同一类最近的多边形的距离。

我正在尝试使用以下代码：

WITH index_query AS (
  SELECT g1.gid As ref_gid, ST_Distance(g1.the_geom,g2.the_geom) As ENN    
    FROM "cosn1" As g1, "cosn1" As g2   
    WHERE g1.gid <> g2.gid AND g1.class = g2.class
    ORDER BY g1.gid, g1.the_geom <-> g2.the_geom) 
SELECT DISTINCT ON (ref_gid) ref_gid, ENN 
    FROM index_query
ORDER BY ref_gid, ENN;

但是后来我意识到了警告：

注意：仅当其中一种几何形状为常数时，索引才会插入（不是在子查询/ cte中）。例如'SRID = 3005; POINT（1011102 450541）':: geometry而不是a.geom

这意味着完全不会使用索引，并且查询将与使用之前几乎相同的时间：

SELECT DISTINCT ON(g1.gid)  g1.gid As ref_gid, ST_Distance(g1.the_geom,g2.the_geom) As ENN    
    FROM "cosn1" As g1, "cosn1" As g2   
    WHERE g1.gid <> g2.gid AND g1.class = g2.class
    ORDER BY g1.gid, ST_Distance(g1.the_geom,g2.the_geom)

谁能为我指出一种解决方法，使我能够提高查询性能？

非常感谢你。

嗡嗡声在我的机器上做一些测试，听起来像此操作符<->无法正常工作。我不确定这是一个错误，但是在不重叠的几何图形上它报告了零距离。有意思吗？

那么公平的传统SQL查询优化又如何呢？由于使用<->运算符的那些意外结果，我将其替换为st_centroid。在速度上有更好的结果。

希望st_overlaps的语义保持不变。至少我从有关<->的文档中了解到

来自Postigs上的文档<->

对于其他几何类型，返回浮点边界框形心之间的距离。

在我的具有约5.5k多边形的测试数据上，没有空间索引的速度从约1000秒增加到了约5秒。

无论如何，为什么要使用DISTINCT ON进行分组？我看到有人在使用它，但是group by不是为了消除重复项而存在吗？

使用标准SQL优化进行查询，不会引入st_centroid错误

select g1.gid, min( st_distance( g1.the_geom, g2.the_geom ) ) AS enn
FROM 
  "cosn1" AS g1, "cosn1" AS g2
WHERE
  g1.gid <> g2.gid
  AND g1.class = g2.class
  AND g1.the_geom && g2.the_geom
GROUP BY
  g1.gid

圣诞快乐！