Renaming a column is simply a matter of updating the catalog table SYSCOLUMN to have the new name. The row data in the table is not affected by the change.... unless you have computed columns in the table, in which case the table is scanned and each computed column value is recomputed and updated if its value has changed (i.e. if the computed column did not change then the row is not rewritten).
The following example shows what happens with a large table that has computed columns that do not change in value.
Here's an example of renaming a column and renaming it back, in a fairly large table using 32-bit SQL Anywhere 184.108.40.2062 on a consumer-grade PC with a 2.66 GHz Core2 Quad Q9450 processor and a 500G drive running 64-bit Windows Vista Ultimate:
ALTER TABLE DBA.rroad_group_2_property_pivot RENAME blocker_row_identifier TO BlahBlahBlah; Execution time: 293.281 seconds ALTER TABLE DBA.rroad_group_2_property_pivot RENAME BlahBlahBlah TO blocker_row_identifier; Execution time: 286.469 seconds
Here's what I mean by "fairly large"... trust me, SQL Anywhere takes a lot longer than 5 minutes to rewrite 22M rows in a 14G table...
-- DBA.rroad_group_2_property_pivot (table_id 735) in Foxhound on bcarter-pc - Oct 19 2010 7:58:23AM - Print - Foxhound © 2010 RisingRoad CREATE TABLE DBA.rroad_group_2_property_pivot ( -- 22,967,920 rows, 14G total = 13.5G table + 56k ext + 542M index, 655 bytes per row ... blocker_row_identifier VARCHAR ( 32 ) NULL, ...
Here's some more evidence that something expensive is going on, but it's NOT rewriting the rows:
How big was the cache? Only 2G, only 1/7th the size of the table, so that doesn't explain the "0 writes".