[Gfoss] SpatiaLite Cookbook: SQL error: no such function: RTreeIntersects

[a.furieri a lqt.it]

La sintassi giusta e':

SELECT
     lc1.lc_name AS "Tuscan Local Council",
     c1.county_name AS "Tuscan County",
     lc2.lc_name AS "Neighbour LC",
     c2.county_name AS County,
     r2.region_name AS Region
FROM
     local_councils AS lc1,
     local_councils AS lc2
     JOIN counties AS c1 ON (c1.county_id = lc1.county_id)
     JOIN counties AS c2 ON (c2.county_id = lc2.county_id)
     JOIN regions AS r1 ON (r1.region_id = c1.region_id)
     JOIN regions AS r2 ON (r2.region_id = c2.region_id)
WHERE
     r1.region_name LIKE 'toscana'
     AND r1.region_id <> r2.region_id
     AND ST_Touches(lc1.geometry, lc2.geometry)
     AND lc2.ROWID IN (
         SELECT ROWID FROM SpatialIndex
         WHERE f_table_name='DB=main.local_councils' AND 
search_frame=lc1.geometry
     )
ORDER BY c1.county_name, lc1.lc_name;

N.B: ... WHERE f_table_name='DB=main.local_councils' ...
e' la sintassi estesa che supporta anche il caso in cui siano
eventualmente presenti degli ATTACHed DB; ma nel nostro caso
e' connesso un unico DB (il primario) e quindi bastava usare
piu' semplicemente la notazione base (senza indicare il
prefisso/alias del DB):
... WHERE f_table_name='local_councils' ...

---------------

comunque se ne scopre sempre una nuova :-D

a partire dalla version 3.8.0 SQLite ha adottato un "next generation
query planner" che "quasi sempre" e' in grado di eseguire le queries
in modo significativamente piu' veloce.
purtroppo in qualche caso "sfortunato" invece il nuovo planner puo'
anche rallentare catastroficamente la velocita' di esecuzione.
(fatto ben noto ed abbondantemente documentato nelle note di
rilascio delle ultime versioni di SQLite)

purtroppo nel caso particolare di questa query specifica abbiamo
proprio un esempio di come il nuovo query planner possa avere un
impatto assolutamente nefasto.
infatti questa query (decisamente complessa) con il nuovo planner
finisce per selezionare come guida l'indice suggerito dalla clausola
ORDER BY: ma cosi' lo spatial index finisce "messo in ombra", e si
ha un rallentamento catastrofico.

se si riscrive la query semplicemente omettendo del tutto la
ORDER BY si scopre invece che la query torna a funzionare a tutta
manetta (proprio come avveniva con le vecchie versioni di sqlite).
tempi oggettivi misurati:

   con ORDER BY: circa 3 minuti
senza ORDER BY: poco meno di 10 secondi :-D

ciao Sandro