Karlin: Https://dev.mysql.com/doc/refman/5.5/en/innodb-compression.html

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