Microsoftif SQL Server can detect SSD/NAND flash storage, further optimizations are warranted. NAND flash operations are: 1) Block erase, 2) program (page), and 3) read. Any writes must go to a blank page. there should be no need for file initialization. A SQL Server file allocation should just reserve the pages. A read of a reserved but unallocated page should return blank (block erase sets cell voltage high, not sure if this is zero or 1).
Also, some specialty SSD/NAND may have small page size, but most are 32KB pages? Unless there is call to change SQL Server page size, is there any way we could try to issue writes in sets of 4 x 8KB pages as much as possible, or at the block size.
Unrelated, I would really like to rethink SQL Server page storage. The 96-byte page header prevents any 64-byte alignment of rows. If the first 16 row offsets could be placed directly after the page header, and the rest stays at the end of the page?
Is there are way for row offsets to load into AVX 256 or 512 bit (32 and 64 byte) registers. And then have AMD/Intel implement additional instructions so that row/column offset calculations are done with values loaded in these registers?
