hanged.
On Tue, 5 Aug 2003, Alexander Keremidarski wrote:
> Joshua,
>
> Joshua Spoerri wrote:
> > On Tue, 5 Aug 2003, Alexander Keremidarski wrote:
> >
> >>MySQL will never use any index for small tables. With just few rows using index
> >>adds over
On Tue, 5 Aug 2003, gerald_clark wrote:
> You are ORing on two different fields. The index cannot be used to
> check the value of z for an OR.
"ORing on two different fields" is what I have been asking about :).
Using a composite index was suggested, which strangely seems to work
only when there
On Tue, 5 Aug 2003, Alexander Keremidarski wrote:
> MySQL will never use any index for small tables. With just few rows using index
> adds overhead only. Table scan is faster in such cases. This is docummented
> behaviour.
is 100,000 rows small? my simple OR queries take longer than a second.
my
Thanks for the suggestion.
This is not ideal for a couple of reasons: I'm using an object-relational
layer that would have to be hacked up something fierce, and my actual
query would be pretty hairy:
(select * from t1 where a=x
union select t1.* from t1,t2 where t1.b=t2.b and t2.c=y
union select
| x | ALL | y | NULL |NULL | NULL |3 | Using
where |
+---+--+---+--+-+--+--+-+
1 row in set (0.00 sec)
On Mon, 4 Aug 2003, Joshua Spoerri wrote:
> That doesn't seem to work (and not with bigger table either):
>
&
ared-compat-4.0.13-0
(Thanks for your help)
On Mon, 4 Aug 2003, Alexander Keremidarski wrote:
> Joshua,
>
> Joshua Spoerri wrote:
> > Which version is targetted for optimization of OR searching on two keys,
> > that is, "select * from sometable where f1 = 123 o
Which version is targetted for optimization of OR searching on two keys,
that is, "select * from sometable where f1 = 123 or f2 = 123",
as described in http://www.mysql.com/doc/en/Searching_on_two_keys.html
?
Thanks
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
T
