funzione postgis lenta

[Luca Delucchi]

Ciao a tutti,

ho creato una funzione in linguaggio sql con alcune funzioni spaziali
e se eseguo il codice con cui creo la funzione con il parametro già impostato
impiega circa 3ms, quando però uso la funzione in una select con 1
punto si incrementa a 1200ms e con 324 elementi impiega 341729.442ms.
La funzione diventa ingestibile con tabelle più grandi.

Il codice della funzione e del test sul singolo punto sono a questo
indirizzo [0], per testarlo così com'è risulta un po' complesso perchè
oltre a postgis bisogna avere i dati di OpenStreetMap caricati con
osm2pgsql.

A me basterebbe qualche consiglio per capire cosa rallenta così tanto le
operazione e come poterlo migliorare.

Grazie

[0] http://pastebin.com/05R0ZYFM

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Luigi Pirelli-2]

supponendo che l'indice spaziale ovviamente ci sia, explain analyze
della query che ti dice?
Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************


2015-11-26 16:29 GMT+01:00 Luca Delucchi <[hidden email]>:

> Ciao a tutti,
>
> ho creato una funzione in linguaggio sql con alcune funzioni spaziali
> e se eseguo il codice con cui creo la funzione con il parametro già impostato
> impiega circa 3ms, quando però uso la funzione in una select con 1
> punto si incrementa a 1200ms e con 324 elementi impiega 341729.442ms.
> La funzione diventa ingestibile con tabelle più grandi.
>
> Il codice della funzione e del test sul singolo punto sono a questo
> indirizzo [0], per testarlo così com'è risulta un po' complesso perchè
> oltre a postgis bisogna avere i dati di OpenStreetMap caricati con
> osm2pgsql.
>
> A me basterebbe qualche consiglio per capire cosa rallenta così tanto le
> operazione e come poterlo migliorare.
>
> Grazie
>
> [0] http://pastebin.com/05R0ZYFM
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 786 iscritti al 30.9.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Luca Delucchi]

2015-11-26 22:01 GMT+01:00 Luigi Pirelli <[hidden email]>:
> supponendo che l'indice spaziale ovviamente ci sia, explain analyze
> della query che ti dice?

ecco quella con un punto e circa 300, quella finale qualche migliaia
di record, gira da un po' di tempo ma non ha ancora finito

osm_ledro=# explain analyze select poi_ldir(st_centroid(way)) as
ldir,name from (select way, name from planet_osm_polygon where
name='Malga Ciapa') as sel;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Seq Scan on planet_osm_polygon  (cost=0.00..58964.63 rows=38
width=243) (actual time=524.527..687.929 rows=1 loops=1)
   Filter: (name = 'Malga Ciapa'::text)
   Rows Removed by Filter: 1133044
 Planning time: 0.630 ms
 Execution time: 687.984 ms

osm_ledro=# explain analyze select poi_ldir(way) as ldir, tourism from
planet_osm_point where tourism='alpine_hut';
                             QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
 Seq Scan on planet_osm_point  (cost=0.00..12431.84 rows=336 width=42)
(actual time=594.090..204201.110 rows=422 loops=1)
   Filter: (tourism = 'alpine_hut'::text)
   Rows Removed by Filter: 280765
 Planning time: 0.598 ms
 Execution time: 204201.359 ms

> Luigi Pirelli
>

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

[Sandro Santilli]

On Fri, Nov 27, 2015 at 12:35:37AM +0100, Luca Delucchi wrote:

> 2015-11-26 22:01 GMT+01:00 Luigi Pirelli <[hidden email]>:
> > supponendo che l'indice spaziale ovviamente ci sia, explain analyze
> > della query che ti dice?
>
> ecco quella con un punto e circa 300, quella finale qualche migliaia
> di record, gira da un po' di tempo ma non ha ancora finito
>
> osm_ledro=# explain analyze select poi_ldir(st_centroid(way)) as
> ldir,name from (select way, name from planet_osm_polygon where
> name='Malga Ciapa') as sel;

Ma e' una query diversa da quella che hai postato qui:
http://pastebin.com/05R0ZYFM

--strk;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015