#513: g.rename extremely slow, speed improvement --------------------------+------------------------------------------------- Reporter: gisboa | Owner: [email protected] Type: enhancement | Status: new Priority: minor | Milestone: 6.4.0 Component: Vector | Version: unspecified Resolution: | Keywords: vector database rename Platform: All | Cpu: All --------------------------+------------------------------------------------- Comment (by glynn):
Replying to [ticket:513 gisboa]: > Renaming a large vector table connected to a postgresql database using v.rename is very time consuming, mostly due to database activity. > Suggestion: send 'alter table rename ...' to postgresql to rename the table, and change the dbln contents, so only renaming operations are involved, no actual data is being moved in this way The DBF driver doesn't support 'ALTER TABLE RENAME ...'. And there's no way for a client to query the capabilities of a particular driver. Suggestion 1: drop support for the DBF driver. Its presence means that everything that uses the DBMI has to limit itself to the tiny subset of SQL which the DBF driver actually understands (e.g.: no joins), often having to adopt inefficient workarounds. Suggestion 2: stop using db_execute() and extend the DBMI with specific commands for each operation. Drivers for real, mostly SQL-compatible backends can just send the appropriate command while the DBF driver can do the necessary hacks. Suggestion 3: upgrade the DBF driver so that it supports at least the basic features of SQL, e.g. joins. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/513#comment:1> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
