Найближча проблема сусіда в Postgis 2.0 за допомогою індексу GIST (<-> функція)

Я намагаюся використовувати нову функцію Postgis 2.0 <-> (Geometry Distance Centroid), щоб обчислити для кожного рядка моєї таблиці (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)' :: геометрія замість 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 для групування? Я бачу, як деякі люди використовують його, але не існує група для усунення дублікатів?

Ваш запит із стандартними оптимізаціями 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

Зі святом Різдва!