Sự cố hàng xóm gần nhất trong Postgis 2.0 khi sử dụng chỉ số GIST (chức năng <->)

Tôi đang cố gắng sử dụng hàm mới Postgis 2.0 <-> (Geometry distance Centroid) để tính toán, cho mỗi hàng của bảng của tôi (cosn1), khoảng cách đến đa giác gần nhất của cùng một lớp.

Tôi đã cố gắng sử dụng mã sau đây:

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;

Nhưng sau đó tôi nhận ra cảnh báo:

Lưu ý: Chỉ mục chỉ khởi động nếu một trong các hình học là một hằng số (không phải trong truy vấn con / cte). ví dụ: 'SRID = 3005; POINT (1011102 450541)' :: hình học thay vì a.geom

Có nghĩa là Index hoàn toàn không được sử dụng và truy vấn sẽ mất gần như cùng thời gian như trước khi sử dụng:

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)

Bất cứ ai có thể chỉ cho tôi một cách giải quyết cho phép tôi cải thiện hiệu suất truy vấn của mình không?

Cảm ơn nhiều.

Hum làm một số thử nghiệm trên máy của tôi nghe có vẻ như toán tử này <-> không hoạt động đúng. Tôi không chắc chắn đó là một lỗi nhưng nó báo cáo khoảng cách bằng không trên hình học không chồng chéo. Có hấp dẫn không?

Vâng, những gì về tối ưu hóa truy vấn SQL truyền thống công bằng? Vì những kết quả không mong muốn với toán tử <-> tôi thay thế nó bằng st_centroid. Có kết quả tốt hơn nhiều về tốc độ.

Hy vọng ngữ nghĩa với st_overlaps giữ nguyên. Ít nhất điều này tôi đã hiểu từ tài liệu về <->

Từ tài liệu trên Postigs <->

Đối với các loại hình học khác, khoảng cách giữa các tâm của khung giới hạn dấu phẩy động được trả về.

Trên dữ liệu thử nghiệm của tôi với ~ 5,5k đa giác đã tăng tốc từ ~ 1000 giây lên ~ 5 giây mà không cần lập chỉ mục không gian.

Dù sao tại sao sử dụng DISTINCT ON để làm nhóm? Tôi thấy một số người sử dụng nó nhưng không tồn tại nhóm để loại bỏ trùng lặp?

Truy vấn của bạn với tối ưu hóa SQL tiêu chuẩn mà không có lỗi st_centroid được giới thiệu

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

Chúc mừng giáng sinh