Cupelli: Hi all, my slow query log is getting large. How do I truncate it without restarting mysqld ?
Werre: I don’t need to retain it at all
Mckever: Domas: thanks. Saw that on stackoverflow, wasn’t sure about it though
Routhier: ICantCook: check logrotate, maybe it points to a default slow log and you use something else
Helmsing: Logrotate would have a problem with slow query logs, since it would need to send a signal to mysqld
Cotrone: Would it be an absolutely horrible idea to us zip/postal as a primary key. with blended us and canadian data, so some entries could be 90210 and others could be 1a1a1a ?
Slicker: What field type should i use for a field that would contain one of those two formats that is the most space efficient, and performant?
Helmsing: Deweydb: a postal code as a primary key?
Swanstrom: Yeah. i want to use it as a lookup index. all the queries will be against that.
Taylar: Maybe i am just an idiot
Routhier: Use a numeric auto_increment surrogate primary key
Helmsing: Deweydb: read about primary keys, and the difference between a primary key, and a regular key/index.
Helmsing: Deweydb: I’m pretty sure you had no idea of what it is when you said it
Artiaga: Yeah, you’re probably correct there buddy
Cuttitta: Ok forget the index stuff, what field type should i use for that?
Helmsing: Routhier: I think he’s just talking about an index on the zip/postal column
Hillberry: You can store a1a1a1 as an int?
Helmsing: Deweydb: if you store both, use varchar.
Mistler: I have some data that contains older dates in the format “2010-01-01 04:00:00 -0700”. Is it best to store this as a unix_timestamp on insert somehow?
Lajoy: Some basic help needed: mysql php functions cause blank page even html is not there but regular php without those functions work. I’m using the linuxmintubuntu repos. I removed the colon from the php’s ini . Do I need to do something with apache? to make php work with mysql? it works without mysql.
Helmsing: Meggings: ask ##php about your WSOD
Helmsing: Mehwork: so what data type is that column using now?
Gilliard: I suppose. it is in the mysql realm of the triad predominantly. but I guess you folks never signed up officially to play with each other. I’ll be off then.
Jacksits: Helmsing: datetime, but i can cahnge it
Sark: Helmsing: the old data isn’t in mysql so it’s not using a date time column. It’s from json
Helmsing: Mehwork: you can’t store ‘2010-01-01 04:00:00 -0700’ in a datetime column – use YYYY-MM-DD HH:MM:SS
Ciciora: Helmsing: wouldn’t that make it lose the utc offset though?
Helmsing: Mehwork: import into a temp table, use INSERT SELECT and str_to_date
Hilaire: Or does it not matter usually
Helmsing: Mehwork: store the offset in another column
Helmsing: Mehwork: you can’t store the offset into a datetime column directly.
Gilliam: No way to convert to iso 8601 or something?
Helmsing: Mehwork: or just apply the offset to the value before storing it.
Helmsing: Meggings: a WSOD has nothing to do with apache httpd or MySQL
Grove: Helmsing: apply the offset to the value how?
Helmsing: Mehwork: using INTERVAL at the INSERT . SELECT stage, or date and time functions
Helmsing: Mehwork: personally, I would store the offset in another column.
Hammer: Helmsing: does it being in a separate column help with recalculating for DST later?
Helmsing: Mehwork: not really. But it’s handy for other reasons.
Helmsing: Mehwork: is your data source all in UTC?
Helmsing: Actually, never mind that, looking at your sample – the offset is applied to the UTC value.
Huizinga: I think so, but it’s hard to say because i get back different json each time