Dollard: Compression is shown to be faster because it reduces the bulk of the time used
Todhunter: Disk I/O and memory bandwidth are more overhead than CPU time
Koskela: The pages are stored in the buffer pool compressed
Sloop: Can I comress on a slave, and not on the master?
Yousko: Im thinking about having a slave for etsting/ backups
Asad: It’s the innodb row format
Mcentegart: You could run into problems with replicated DDL though
Hughen: It will replicate without issue having different row formats?
Gilster: Between master and slave?
Miesen: If the master is not compressed, when a table rebuild happens on the slave it’ll undo the compression
Hallford: Schema definition statements
Gronitz: I’d have to test it, but a simple ALTER shouldn’t replicate the row format
Strausz: Some more elaborate statements may cause ROW_FORMAT to replicate in the binlog
Merlain: Im planning on the binlog format being row
Akers: DDL statements are replicated in STATEMENT format regardless
Archibald: Ill save compression for a next step
Neifer: Too much to do already 😛
Hinzman: If I’m storing a list of playernames in a table, is it a bad idea to use varchar as the primary key? Should I ***ign an id instead? I intend on playernames being unique
Mccloud: Tylak: typically you would ***ign a numeric ID as a primary key, if you want to enforce uniqueness, create a secondary UNIQUE index on the playername
Lenser: Pedward Deason domas: thanks for the help
Abetrani: Well, it’s quitting time here, bye
Raeside: Don’t have too much fun
Roby: I said ‘hi’ to Ben for you
Konieczka: I may or may not write a blog post
Pontius: Tell Ben that MySQL optimizer is stupid
Soldan: If you do, don’t forget to link to your previous post
Heppeard: This one is related too http://dom.as/2015/07/30/on-order-by-optimization/
Erby: Domas: do you think he doesn’t know that? I mean, it’s not like you guys are exactly quiet on the subject
Andino: In the essence of “what ***umptions optimizer has when it does something very very stupid”
Cardinale: Yeah, the doc page on the optimizer switches doesn’t touch on the tweaks ***ociated with each optimizer helper
Vassey: So a blog post that touches on all of that in one place could be useful
Battie: Ok, time to really go.
Holsonback: Oh, funny, I think Morgan’s optimizer challenge can be beaten by this
Hartgraves: It is very easy to make a case where MySQL will come up with better query plan under MyISAM :
Bendtsen: I have a bunch of dates stored as VARCHAR eg: a2015-01-11 07:00:00 and need to do some date calculations. Is STR_TO_DATE the correct method?
Moure: I have a bunch of dates stored as VARCHAR eg: 2015-01-11 07:00:00 and need to do some date calculations. Is STR_TO_DATE the correct method?
Bachinski: Shai-Tan: That’s a good fallback. better idea is to store your data in the correct data type
Shake: Yeah, cannot change it. I tried and it broke the application not of my design
Bachinski: Shai-Tan: it is what it is. str_to_date then
Bachinski: Shai-Tan: just be aware that wrapping a function around the value precludes the use of an index on that column
Solazar: 2015-09-11 07:01:34 works fine, but 2015-09-16 11:17:19 returns NULL
Hemlepp: STR_TO_DATE usr_last_sync_time, ‘%Y-%m-%d %h:%m’ AS usr_last_sync_time
Bachinski: Shai-Tan: select STR_TO_DATE’2015-09-16 11:17:19′, ‘%Y-%m-%d %h:%i:%s’ AS usr_last_sync_time;
Bachinski: Shai-Tan: read closely