ooutwire

@martin Also, my goal was to show that 36B is NOT actually reserved for the slot array. I read that a million times in the last month. It may have been true at some point; but one can say now, at least, that the 36B is for slot array and tags/pointers.

@martin Yeah, I agree. The only reason I called the "future use" answer bogus is that I see no harm in MS just telling us that there will be a 20B cost involved in a case like this one (maybe they have somewhere).

@martin Works on 08R2 as well. Interesting bug though if repeatable. I tweeted Paul, but I assume this is just a pest issue. I guess 20B is the lower limit unless one adds more columns and goes to m_freeCnt = 0 that way. Guess people with many single-row & two-column pages just have to eat the 20B as waste.

@martin I think the answer "20B reserved for future use" is bogus. The truth seems to be that for a single row with two columns, the closest one can come to m_freeCnt = 0 is 20B leftovers.

@martin I did that too without error. FYI, I am using SQL Server 2012

@martin I see no issue with this update: UPDATE tbl SET j = REPLICATE('a',53) ; GO

@martin I get a null pointer and this for row overhead 5000791f.....020000 00000000 00000000 e8020000 0000 That is 14B of something. Version Information = Transaction Timestamp: 744 Version Pointer: Null

@martin My biggest gripe is when I read everywhere that the 36B is for the slot array, which just seems like some kind of crap hand-waving argument.

@martin All I could think of yesterday for the 34 bytes is some reserved overhead for Uniquifier (4B), FORWARDING_STUB (9B), Version Tags (14B)...that gets me to 30B; but as you said, you just get a new page with a ROW_OVERFLOW_DATA allocation unit.

@martin That is what bugs me. I can fill a page to m_freeCnt = 0 but if I want just one row I can max it out and still have the 34 bytes left (36B - 2B slot count for my one row). So, even with a fill factor of 100%, I can get pages with 34B of wasted space. This was the reason I asked my question about heaps vs. CIXs yesterday. Obviously, a full page is not likely a good idea in most cases.