Le 17/03/2011 19:47, [email protected] a écrit :
On Thu, 17 Mar 2011 18:48:51 +0100, MORREALE Jean Roc wrote
Ticket #3002 may be linked, it is reproducible on windows/linux.
Hi Jean Roc,
ticket #3002 isn't related at all to SpatiaLite
and/or to the QGIS own SpatiaLite data provider.
I've just attempted to save a (quite small sized)
Shapefile as a SQLite DB following the procedure
reported on ticket #3002.
Yes, I can confirm, you are perfectly right: the
export process is incredibly slow (> 10 minutes)
and strongly inefficient (spatialite_gui performs
the same identical task just in few seconds).
Anyway, at the end of the process a basic SQLite
DB was generated.
Please note well: this is *not* at all a SpatiaLite
own DB; this one is an OGR/FDO own DB (a completely
different thing, using an independent code base).
Sorry for the mistake, I didn't knew there was a difference in the ouput.
So for sure this issue is entirely caused by OGR,
and has absolutely nothing to do with SpatiaLite.
Just as a working hypothesis: during this painful
export I noticed a very low CPU activity, and an
impressively huge disk traffic.
This is exactly what I'm expecting from a badly
implemented process attempting to perform lots and
lots of SQL INSERTs without declaring a corresponding
BEGIN and COMMIT ... and such a condition notoriously
is a real "performance killer" for any transactional
DBMS. my 2 cents :-)
Can you confirm that it is due to OGR ? ogr2ogr with SPATIALITE=yes is
faster than QGIS 'save as'
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
