Robert DiFalco wrote:
Here's an odd one.
I have a table called Elements and another table called ElementNames.
The ElementNames table has a unique ID and a VARCHAR display name. The
Elements table has a ElementName.ID, a node ID, a rule ID and some other
stuff.
I have an index on the NameID,
: Glitch in Query Optimizer
On Tue, Oct 03, 2006 at 01:35:01PM -0700, Robert DiFalco wrote:
Scratch that, the only way to have the optimizer choose the correct
index is to remove all compound indices that start with NodeID or
move NodeID so that it is not the first column specified
Message-
From: Christian Hammers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 03, 2006 2:54 PM
To: Robert DiFalco
Cc: mysql@lists.mysql.com
Subject: Re: Glitch in Query Optimizer
On Tue, Oct 03, 2006 at 01:35:01PM -0700, Robert DiFalco wrote:
Scratch that, the only way to have
Scratch that, the only way to have the optimizer choose the correct
index is to remove all compound indices that start with NodeID or move
NodeID so that it is not the first column specified in the compound
index. Ugh. Any ideas?
-Original Message-
From: Robert DiFalco [mailto:[EMAIL
Have you tried using the USE/IGNORE/FORCE INDEX optimizer hints?
http://dev.mysql.com/doc/refman/5.0/en/join.html
Sometimes, MySQL's optimize just doesn't make the best choice.
Somewhat rare in my experience but it happens.
HTH,
Dan
On 10/3/06, Robert DiFalco [EMAIL PROTECTED] wrote:
Scratch
: Re: RE: Glitch in Query Optimizer
Have you tried using the USE/IGNORE/FORCE INDEX optimizer hints?
http://dev.mysql.com/doc/refman/5.0/en/join.html
Sometimes, MySQL's optimize just doesn't make the best choice.
Somewhat rare in my experience but it happens.
HTH,
Dan
On 10/3/06, Robert DiFalco
On Tue, Oct 03, 2006 at 01:35:01PM -0700, Robert DiFalco wrote:
Scratch that, the only way to have the optimizer choose the correct
index is to remove all compound indices that start with NodeID or move
NodeID so that it is not the first column specified in the compound
index. Ugh. Any ideas?