magari non interessa a tutti, ma sicuramente e'
un dettaglio tecnico che potra' interessare diversi
power users che si trovano a manipolare grosse
quantita' di dati con ogr2ogr
ho scoperto (abbastanza casualmente) che ogr2ogr
e' incredibilmente lento quando il target di
destinazione e' uno Spatial DBMS Transactional:
quanto segue e' misurato su SpatiaLite, ma immagino
che anche PostGIS (Oracle, SQL Server ...) abbiano
esattamente il medesimo problema.
la causa di questa mortale lentezza in scrittura
va identificata nel fatto che ogr2ogr invoca una
operazione di COMMIT TRANSACTION troppo frequentemente,
mandando continuamente in stallo l'I/O del DBMS
tuttavia esiste un piccolo, oscuro argomento che
permette di configurare flessibilmente questo aspetto;
peccato che la documentazione di ogr2ogr non lo metta
nella debita edivenza avvertendo della criticita'.
-tg 65536 [capisce anche l'alias -gt, =Group Transaction]
spiegazione ultra-veloce: by default ogr2ogr assume
-tg 200; cioe' ogni 200 INSERT (oppure quando cambia
layer) effettua una COMMIT
specificando esplicitamente -tg 65536 invece si chiede
ad ogr2ogr di effettuare una COMMIT ogni 65536 INSERTs
test case
----------
input: un file GML topologico da 2,8 GB (grosso bestione)
output: SpatiaLite 3.0.0 con Spatial Index abilitati
(100+ layers, molti milioni di features)
test #1 (default): 4 ore e mezza
test #2 (-tg 65536): 1 ora :-)
... quella che si chiama una "differenza apprezzabile" :-P
ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
540 iscritti al 4.11.2011
