Problem Najbliższego sąsiada w Postgis 2.0 przy użyciu indeksu GIST (funkcja <->)

Próbuję użyć nowej funkcji Postgis 2.0 <-> (Centroid Distance Geometry), aby obliczyć dla każdego wiersza mojej tabeli (cosn1) odległość do najbliższego wielokąta tej samej klasy.

Próbowałem użyć następującego kodu:

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;

Ale wtedy zdaję sobie sprawę z ostrzeżeniem:

Uwaga: Indeks jest uruchamiany tylko wtedy, gdy jedna z geometrii jest stała (nie w podzapytaniu / cte). np. „SRID = 3005; POINT (1011102 450541)” :: geometria zamiast a.geom

Oznacza to, że Indeks w ogóle nie będzie używany, a zapytanie zajmie prawie taki sam czas, jak przed użyciem:

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)

Czy ktoś może wskazać mi obejście, które pozwala mi poprawić wydajność mojego zapytania?

Dziękuję Ci bardzo.

Hum podczas niektórych testów na moim komputerze brzmiał tak, jakby ten operator <-> nie działał poprawnie. Nie jestem pewien, czy to błąd, ale zgłosił zerową odległość dla nie nachodzących na siebie geometrii. Intrygujące nie?

A co z uczciwymi tradycyjnymi optymalizacjami zapytań SQL? Ponieważ te nieoczekiwane wyniki z operatorem <-> zastępuję go st_centroid. Osiągnął znacznie lepsze wyniki w zakresie prędkości.

Nadzieja, że ​​semantyka z st_overlaps pozostają takie same. Przynajmniej zrozumiałem to z dokumentacji dotyczącej <->

Z dokumentów na Postigs <->

Dla innych typów geometrii zwracana jest odległość między centroidami obwiedni zmiennoprzecinkowych.

Na moich testach dane z ~ 5,5k wielokątów przyspieszyły z ~ 1000 sekund do ~ 5 sekund bez indeksowania przestrzennego.

W każdym razie, dlaczego używasz DISTINCT ON do grupowania? Widzę, że niektórzy ludzie go używają, ale grupa nie istnieje, aby wyeliminować duplikaty?

Twoje zapytanie ze standardowymi optymalizacjami SQL bez wprowadzonego błędu 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

Wesołych Świąt Bożego Narodzenia!