Deason: Oh i think that is normal for 5.6 to say

Deason: Nothing about “future” right?

Deason: That’s fine for 5.5 5.6 is less scary

Robella: Deason: no there is nothing like “future” in the log.

Deason: Most likely everything is fine

Deason: You would only have a problem if you did kill -9 mysqld or set innodb_fast_shutdown=2 in my.cnf

Intermill: Deason: ok. neither is the case. anything else I should tweak before retrying the import?

Deason: Asdfoo: innodb_buffer_pool_size if you didnt set it. the stuff in that wiki i sent you.

Roehrig: Deason: ok. this one i have already. also the i/o sched. but i’m a bit tentative with “set global sync_binlog” and “innodb_flush_log_at_trx_commit” as I don’t understand these yet.

Deason: You can safely set innodb_flush_log_at_trx_commit=2 during the import and set back to 1 when it finishes unless your linux server crashes

Deason: Then at most you loose a couple transactions

Deason: Your issue was likely solved with the redo log fix

Darsi: Deason: I started the import again and it is MUCH fast now. many thanks again!

Base: Hi guys, whats the best approach, if dont exist in table then insert, if exist update.

Terhune: I’m literally ripping my hair out trying to figure out what wrong with this query: http://hastebin.com/cizoxufavi.sql – anyone got any ideas?

Felker: Do you have any photos of the hair ripping?

Decoux: DubstepCraig: don’t use SET

Decoux: DubstepCraig: and follow the manual

Mckinna: What’s the meaning behind SELECT Reservations.user_id, LargeCabins.place_id FROM Reservations, SELECT place_id FROM places WHERE size=’large’ LargeCabins EXCEPT SELECT user_id, place_id FROM Reservations

Durley: Ackpacket: there is no EXCEPT Niedzwiedzki. its in the sql standard but not implmented in mysql.

Egge: Danblack: Hmm. Ok, ty. I suppose the write should have specified what they intended to use.

Eimers: Danblack: Logically speaking though, would that produce the null set?

Tatters: Couldn’t be bothered to work it out.

Talyor: Ask what you want to acheive.

Boghossian: Also don’t join with a ,

Helper: Danblack: I’m trying to p**** what’s already been written for studying purposes, so I can’t say that I have an end goal in mind

Twiddy: There is no join criteria between Reservations and placesLargeCabins.

Bayus: Right, so it would be a cross product

Sumey: Ackpacket: it would be the opposite of cross product

Daul: Boleware: A join without criteria?

Fergason: EXCEPT removes data returned by the right statement from results of the left statement

Sinard: Ackpacket: SELECT a.* FROM a LEFT JOIN b ON a.id = b.id WHERE b.id IS NULL;

Progacz: This is a way to do it in mysql

Leverett: I appreciate you weighing in, but tbh I’m feeling drained from staring at this. I’m about to head out.

Stater: But I would like a sanity check on this statement

Capalongan: Can I say that for a user to be returned in this query, they have to have reserved a place, but not have reserved all large cabins?

Ambrosio: Actually, Reservations, SELECT place_id FROM places WHERE size=’large’ LargeCabins this is a crossjoin without condition

Digby: It looks that for every reservation it returns all large cabins except the ones that the user reserved before

Lowy: Well, if a user has not made a reservation, they won’t show in that query

Barbiere: I think we agree on that

Marlow: But if they have reserved all of the large cabins, then they will be removed entirely when the EXCEPT goes into effect

Lyford: Because every combination of that user and a large cabin, created by the join, will already be a combination present in reservations