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