One of the things I’ve been doing lately is looking forward to future versions of SQL Server. Not SQL 11/Denali, which has CTP 3 out now, but more towards the future. SQL 12 and beyond, and wondering how the platform can advance and incorporate new ideas and knowledge from other areas such as NoSQL or NewSQL. I also have been trying to decide which parts of SQL Server could be improved to be more robust of scalable, or address some failings in the platform.
Our systems seem to be growing larger, and storage seems to cost less all the time. While this doesn’t always result in cost savings, it does mean that we may be ready to increase the page size in SQL Server once again, perhaps growing to 16k or even 64k. If that follows as I/O transfer sizes grow, then is it time to add in a rowid marker of some sort that gives us a unique handle to every row on a page?
I know this adds some overhead, and in reading about the internals of current pages, that overhead can be significant. However it seems that I find people that regularly have non-unique clustered indexes, or heaps, and could require SQL Server to differentiate the rows internally. With our busses increasing in size and larger sectors on disks, perhaps the overhead isn’t out of the question.
This would allow for some interesting benefits for replication, with the possibility that any object could be replicated, no matter what the structure. It also might allow us to very efficiently eliminate duplicates and perhaps improve the efficiency of some T-SQL commands.
What do you think? Is it time for a true ROWID? Time to increase the page size for SQL Server?