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
MySQL is using the index in both of those. The first query
where changed < 7890; should be very fast since explain says it
only has to find one row. The second query, after mysql does a range
scan on the index has to still examine 11551351 rows to find a max
value.
The last query SELECT MAX(ch
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
>
> > -Original Message-
> > From: Dave Dyer [mailto:[EMAIL PROTECTED]
> > Sent: Friday, September 03, 2004 7:04 PM
> > To: [EMAIL PROTECTED]
> > Subject: please explain why this query isn't optimized
> >
> >
> > Before I post it a
essage-
> From: Dave Dyer [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 03, 2004 7:04 PM
> To: [EMAIL PROTECTED]
> Subject: please explain why this query isn't optimized
>
>
> Before I post it as a bug, perhaps someone can explain why
> this query is not op
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;
++---+---+-+-+--+-+---
13 matches
Mail list logo
