[GRASS-dev] Re: [GRASS GIS] #513: g.rename extremely slow, speed improvement

[GRASS GIS]

#513: g.rename extremely slow, speed improvement
--------------------------+-------------------------------------------------
  Reporter:  gisboa       |       Owner:  grass-dev at lists.osgeo.org
      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>