different desc for same statement

2011-08-31 Thread walter harms
hi list, i have a very strange effect. I have two boxes with the same DB ( same version, same tables, same my.cnf, etc) I was trying to optimise an sql statement and used desc to see what is going on and found to my surprise two different results. Can this be the result of the optimizer ? (the

Re: locked non-existent row

2011-08-31 Thread Rik Wasmus
While a transaction in one thread tries to update a non-existent InnoDB row with a given key value, an attempt to insert that value in another thread is locked out. Does anyone know where this behaviour is documented? -- connection 1 drop table if exists t; create table t( lockid char(3),

Re: utility of an index

2011-08-31 Thread Johan De Meersman
- Original Message - From: Dave Dyer ddyer=my...@real-me.net It depends on if you want the forest or the trees. A frequently executed query asks for just the robots. An index is an efficient way to select 6 of 20,000. As for why the rest are null, null is just a a random

Re: different desc for same statement

2011-08-31 Thread Johan De Meersman
Exactly the same data, too? Different index leaf distribution might account for something like this, and it does look like you're retrieving different datasets. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General

Re: different desc for same statement

2011-08-31 Thread walter harms
Am 31.08.2011 13:51, schrieb Johan De Meersman: Exactly the same data, too? Different index leaf distribution might account for something like this, and it does look like you're retrieving different datasets. same data think of it as a backup. re, wh -- MySQL General Mailing List For

Re: locked non-existent row

2011-08-31 Thread Peter Brawley
On 8/31/2011 4:50 AM, Rik Wasmus wrote: While a transaction in one thread tries to update a non-existent InnoDB row with a given key value, an attempt to insert that value in another thread is locked out. Does anyone know where this behaviour is documented? -- connection 1 drop table if exists