Overweg: Same mysql verision though
Postle: Virhilo: That’s a bad sign. What version of mysqld?
Nickols: Virhilo: Do you have a script that can be used to duplicate the behavior? Have you tried to reduce the script to something minimal that still causes the crash?
Tedrick: Virhilo: Just that create table statement alone is probably not enough.
Noecker: Xgc: actually its these constraints it seems
Muskthel: Xgc: ok, guess what?:
Shelkoff: Xgc: my FK was signed int referenced column was unsigned:f
Mallory: Virhilo: That should *never* cause the server to crash.
Varieur: Virhilo: did your server crash? Do you have any evidence that it did?
Zastawny: 02:15:49 UTC – mysqld got signal 11 ;
Horsfield: So, would queries on my table using the composite primary key from 3 columns be faster or slower than using an autoincrment key?
Boswink: Varieur: it crashed and restarted itself
Galathe: JFlash: You’ll need to test.
Reinheimer: Varieur: http://paste.ofcode.org/3rk895HTeEC7frX4NbWkSf
Bartoldus: Remember, we are talking potentially millions of rows here
Dwan: JFlash: or you could just guess.
Varieur: JFlash: MySQL can handle billions of rows.
Weisenborn: Ah ok, i just wante to know if composites where inherently slower
Varieur: Virhilo: pray tell, what version of MySQL is this?
Hamm: Although if you are planning for billions of rows make sure to use BIGINT for your autoincrement fields !
Walka: Varieur: 5.5.44-0ubuntu0.14.04.1
Welshans: Yes but the problem is that access frequency. in a live app I will be scannin table thousands of times per second. that’s way I ask. but never mind. I just wanted to know if there was much slower than the alternative
Moury: OS error code 11: Resource temporarily unavailable
Watah: Varieur: so bit old-ish:f
Varieur: Virhilo: I’d be more inclined to blame your RAM
Hussain: Varieur: well i changed that query and no more issues
Balandran: How do I query a composite prim key table?
Katoh: Speaking of auto_increment : I am finding it increments and if I delete records, it continues to increment as if those old record numbers were still in use. 10 records – delete 5, still results in the next increment in being 11?
Hamm: That’s siginal 11 not error code 11.
Ulwelling: Does anything change?
Varieur: Virhilo: accessing a corrupted memory module.
Varieur: MikeJoel: yes, that’s normal.
Michaels: JFlash: You may be making this more complicated then needed. 1 Determine your requirements. 2 Determine the acceptable alternatives that meet your requirements 3 Pick the one you like best.
Varieur: Hamm: I know, I just wanted to check
Bowring: Varieur: on 2 machines?:f
Kotzen: Varieur: I figured it was checking the last incremented value before incrementing. is there something I could do to get it to act as I expected?
Varieur: MikeJoel: gaps are expected.
Varieur: MikeJoel: so, you don’t need to do anything.
Feichtner: Xgc, it’s easy for you. youve done it before 😛
Avants: Varieur: what happens when you have so many gaps that you run out of increment range?
Rayman: JFlash: It’s immaterial if you think a composite key is slow or fast. Determine if that’s one of the options and compare it to any other options you have. Then pick one.
Varieur: MikeJoel: use BIGINT UNSIGNED
Varieur: MikeJoel: you’ll never run out of values.
Fruits: I think I’m going in the right direction thou. that’s what is important to me. thank you for your advice
Duclos: JFlash: There’s often not one answer independent of your data.