JFlash: There’s often not.

organic
No comments yet

 
Overweg: Same mysql verision though

Postle: Virhilo: That’s a bad sign. What version of mysqld?

Lenton: 5.5.44-0ubuntu0.14.04.1

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.