#513: g.rename extremely slow, speed improvement
------------------------------------+---------------------------------------
Reporter: gisboa | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.0
Component: Vector | Version: unspecified
Keywords: vector database rename | Platform: All
Cpu: All |
------------------------------------+---------------------------------------
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
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.