Takeaway: Deleting columns does not reduce the width of a record (including new ones). Tables have to be rebuilt in order to reclaim space.
So I had the opportunity to talk to Michelle Ufford (SqlFool.com) last November after her PASS Summit Talk. We wondered what happens to the space taken by columns after they’ve been deleted. For example, you may be removing columns or altering columns in order to reduce a records’ width. The improved bytes/row (and rows/page) can provide a huge benefit to performance.
Michelle thought it was a great idea for a blog topic and so did I. But Michelle graciously agreed to let me be the one to write it up (I understand she’s busy this month). So here’s the main question: What does happen to the space taken by columns that have been deleted? The naive idea that SQL Server magically cleans it up is wrong, for example:
First I create a table with really inefficient columns:
CREATE TABLE NAME ( id INT IDENTITY PRIMARY KEY, FIRST CHAR(1000) NOT NULL, middle CHAR(1000) NOT NULL, LAST CHAR(1000) NOT NULL ); GO
INSERT NAME (FIRST, middle, LAST) VALUES ('Michael', 'J', 'Swart'); INSERT NAME (FIRST, middle, LAST) VALUES ('Lester', 'B', 'Pearson'); INSERT NAME (FIRST, middle, LAST) VALUES ('Mack', 'D', 'Knife'); INSERT NAME (FIRST, middle, LAST) VALUES ('Homer', 'J', 'Simpson');
These four rows I put in take up two data pages like this:
Remember, each page is 8 Kb long. So lets remove the middle column and right-size the others like this:
ALTER TABLE NAME DROP COLUMN Middle; ALTER TABLE NAME ALTER COLUMN FIRST VARCHAR(20) NOT NULL; ALTER TABLE NAME ALTER COLUMN LAST VARCHAR(20) NOT NULL; -- And add a couple rows for good measure: INSERT NAME (FIRST, LAST) VALUES ('Bartholomew', 'Simpson'); INSERT NAME (FIRST, LAST) VALUES ('Lisa', 'Simpson');
So things should look better right? Not quite! The old data pages haven’t changed at all and the new data looks just as bad:
What’s Happening
The action of dropping columns is not an operation that affects existing data. It’s a meta-data operation only. You can actually see this at work using the slightly undocumented view sys.system_internals_partition_columns. The is_dropped field indicates that the columns haven’t disappeared, they’ve just been marked as dropped:
SELECT t.name AS tablename, c.name AS columnname, ipc.* FROM sys.system_internals_partition_columns ipc join sys.partitions p ON ipc.partition_id = p.partition_id join sys.tables t ON t.OBJECT_ID = p.OBJECT_ID LEFT join sys.columns c ON c.OBJECT_ID = t.OBJECT_ID and c.column_id = ipc.partition_column_id WHERE t.name = 'NAME' ORDER BY c.column_id
So just how hard is it to get rid of columns?
Hair Makes Removing Columns Possible
How to Really Get Rid of Columns
It turns out that an index REBUILD is required (A REORGANIZE isn’t good enough). If you have have a maintenance plan it might eventually take care of this. Or you can do this explicitly:
ALTER INDEX ALL ON NAME REBUILD;
Things look much nicer now:
The information in the diagram above is hard to see, but it works out to about 200 rows per page as we had hoped. The column is truly deleted now which you can see using this query (once again):
SELECT t.name AS tablename, c.name AS columnname, ipc.* FROM sys.system_internals_partition_columns ipc join sys.partitions p ON ipc.partition_id = p.partition_id join sys.tables t ON t.OBJECT_ID = p.OBJECT_ID LEFT join sys.columns c ON c.OBJECT_ID = t.OBJECT_ID and c.column_id = ipc.partition_column_id WHERE t.name = 'NAME' ORDER BY c.column_id
Other Blogs have treated this topic before e.g.:
- Andras at Simple Talk last year.
- Kalen Delaney whose name is almost synonymous with SQL Internals looked at this in 2006.
But none of those have pictures of Samson, do they?
