Time for a ROWID?

Do we need a ROWID structure in all SQL Server tables?

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?

Steve Jones


The Voice of the DBA Podcasts

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

2 Responses to Time for a ROWID?

  1. Kent says:

    It would be good to have the option of setting the page size, perhaps at the filegroup level, even if from a predefined list. Would be most beneficial in the warehouse/data mart arena I think.

    I’m not too sure I follow your rowid thread. SQL Server obviously has one internally for heaps and forces uniqueness on a clustered index with the addition of an int if required. If the developer/dba needs one then I would add it to the table explicitly – even if it doesn’t add value to the data. Like you say, storage is cheap an extra int (or even bigint) column isn’t that much of a cost. Make it an identity column and you automatically have your unique reference.


    • way0utwest says:

      I am mostly thinking of replication here, or third party applications where you cannot alter the schema. Having a defined rowid, not necessarily exposed in something like SELECT *, could have the advantage of a more consistent handle that allows you to work with the row in new ways.


Comments are closed.