> I do not believe it is so much about performance but perhaps at some time > RDBMS whith is accessed through a slow network would get a timeout and > decides to do a rollback. And RDBMS must also reserve resources for being > able to rollback the whole transaction. The -gt option is still there and > 20000 is hundred times more than 200 so it feels like a good new default. > > Actually I have been thinking that rollbacks with ogr2ogr are rather > useless. If RDBMS rollbacks just one block user must still try again with > the whole dataset because there is no way to know which transaction failed > and having 999800 rows out of million written into DB is as good as having > no rows at all. Thus it could be a good strategy to try to do the whole > conversion into database as a one single transaction. Then the rollback > would behave in a logically correct way with ogr2ogr "either all or > nothing". The cost was discussed already: reserved DB resources for being > able to do rollback. But perhaps this is not enough strong argument for > having an ogr2ogr option "-gt auto" for single transactions. ev
I agree, especially in the case of driver such as PostgreSQL with its MVCC system. Of course this is possible when using the OGC API when using the layer StartTransaction CommitTransaction methods. As a side issue I've often thought it would be a good idea to have the transaction control at the datasource level so multiple layers can be updated within the same transaction. Cheers, Jeremy This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [email protected]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
