Timeline for Does MySQL guarantee atomic upgrade from read lock to write lock?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2014 at 11:39 | vote | accept | Rolf NB | ||
| May 20, 2014 at 11:37 | comment | added | Rolf NB | It's not a primary key. PK is autoincrement. Secondary key is an integer hash. The thing that's missing is a hypothetical unique index on a smalltext column, and I'd expect that to be huge no matter the storage engine, but particularly for InnoDB. This is an implementation detail of one solution to the age-old "how do I get auto-increment ids of all this stuff I've inserted in the last two days" problem. Typical table size is ~520M rows, ~75GB (though that's already converted to a zlib compressed TokuDB table, which is done after the table contents are final -- it's faster that way). | |
| May 19, 2014 at 11:46 | comment | added | user1822 | Why would a primary key "quadruple" the size of the table? | |
| May 19, 2014 at 10:20 | answer | added | RandomSeed | timeline score: 0 | |
| Apr 23, 2014 at 14:33 | history | tweeted | twitter.com/#!/StackDBAs/status/458977078432759808 | ||
| Apr 23, 2014 at 14:12 | review | First posts | |||
| Apr 23, 2014 at 14:15 | |||||
| Apr 23, 2014 at 14:00 | history | edited | user1822 | edited tags | |
| Apr 23, 2014 at 13:52 | history | asked | Rolf NB | CC BY-SA 3.0 |