Oops, haven't noticed that these are InnoDB tables. The behavior of
optimization and even explain are much different for InnoDB tables.
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.net http://www.ensita.net/
__ ___ ___
David T-G <[EMAIL PROTECTED]> wrote:
> % Well, actually, there are 2.878 Meg rows, or 2878k.
>
> FYI, you're both right. Americans write numbers as x,xxx,xxx.xx while
> Europeans typically write them as x.xxx.xxx,xx (dot as thousands
> separator and comma as decimal separator).
But programmers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill, et al --
...and then Bill Easton said...
%
% Well, actually, there are 2.878 Meg rows, or 2878k.
FYI, you're both right. Americans write numbers as x,xxx,xxx.xx while
Europeans typically write them as x.xxx.xxx,xx (dot as thousands
separator
ed | 4 | NULL | 52802
| Using where; Using index |
++---+---+-+-+--+---
+--+
1 row in set (0.00 sec)
== original message follows ==
From: Egor Egorov <[EMAIL PROTECTED]>
Date: Mon, 06 Sep 2004 13:
Dave Dyer <[EMAIL PROTECTED]> wrote:
> Before I post it as a bug, perhaps someone can explain why
> this query is not optimized to use the index (it has to examine all 287k rows).
>
> mysql> explain SELECT MAX(changed) FROM archived_stats where changed>0;
> | table | type | possible_key
n Nelson
> Cc: Donny Simonton; [EMAIL PROTECTED]
> Subject: Re: please explain why this query isn't optimized
>
>
> >
> >> Getting the same answer, from a simpler query, in infinitely
> >> less time, just seems wrong to me.
> >
> >Ma
>
>> Getting the same answer, from a simpler query, in infinitely
>> less time, just seems wrong to me.
>
>Makes perfect sense. Simpler queries *are* easier to optimize, you
>know :)
Makes perfect sense. Thanks, I think the relevant points
have been covered.
--
MySQL General Mailing List
Fo
In the last episode (Sep 03), Dave Dyer said:
> At 05:39 PM 9/3/2004, Donny Simonton wrote:
> >It would help if you would say how many entries do you have for
> >changed =0 and how many are greater than 0.
> >
> >Since changed is a timestamp you should never get an entry of 0. So
> >the query of c
At 05:39 PM 9/3/2004, Donny Simonton wrote:
>It would help if you would say how many entries do you have for changed =0
>and how many are greater than 0.
>
>Since changed is a timestamp you should never get an entry of 0. So the
>query of changed>0 will always do a full table scan. This is defini
In the event that mysql has to scan the entire table it will ignore
the index because it's faster to read straight through the datafile
than it is to seek on the index.
-Eric
On Fri, 3 Sep 2004 19:39:38 -0500, Donny Simonton <[EMAIL PROTECTED]> wrote:
> It would help if you would say how many e
It would help if you would say how many entries do you have for changed =0
and how many are greater than 0.
Since changed is a timestamp you should never get an entry of 0. So the
query of changed>0 will always do a full table scan. This is definitely not
a bug.
Donny
> -Original Message--
11 matches
Mail list logo
