|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Today @ 5:18 AM
Points: 494,
Visits: 2,154
|
|
I have a table with 56 million rows. I performed the following operation:
ALTER TABLE MyBigTable ADD NewHashColumn AS HASHBYTES('SHA2_512', Column1+Column2+Column3)
The operation took a fraction of a second to complete. How is this possioble?! I mean can SQL Server really generate so many hash keys in such space of time?!
I'm guessing that the table was already in memory and all this operation took place in memory? Will the next checkpoint write the actual hash codes to the disk?
----------------------------------- http://www.SQL4n00bs.com
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Yesterday @ 9:38 AM
Points: 422,
Visits: 779
|
|
| If I were to guess from my limited knowledge of Hashbytes that this is treated like a computed column and doesn't actually store anything, only returning a value on select.
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Today @ 5:18 AM
Points: 494,
Visits: 2,154
|
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 4:48 AM
Points: 6,728,
Visits: 11,774
|
|
If you had added PERSISTED when adding the computed column there is a possibility you might still be waiting for that complete
__________________________________________________________________________________________________ There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Believe you can and you're halfway there. --Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
|
|
|
|