On Sun, Jan 11, 2009 at 9:31 PM, mos wrote:
> At 03:25 PM 1/11/2009, you wrote:
>>
>> On Sun, Jan 11, 2009 at 2:24 PM, mos wrote:
>> > Yesterday I decided to take the plunge and upgrade from MySQL 5.01 to
>> > 5.1.30
>> > because after all, it was Saturday and what else is there to do on a
>> > S
At 03:25 PM 1/11/2009, you wrote:
On Sun, Jan 11, 2009 at 2:24 PM, mos wrote:
> Yesterday I decided to take the plunge and upgrade from MySQL 5.01 to
5.1.30
> because after all, it was Saturday and what else is there to do on a
> Saturday?
>
> I'm running it on XP Pro with 3gb ram and used the
In the last episode (Oct 27), David Hillman said:
> On Oct 27, 2006, at 11:50 AM, Dan Nelson wrote:
> >MySQL is just giving you as much information as it can without
> >actually running the query. It knows how it will go about running
> >the query (so "type" is known absolutely), but it doesn't kn
On Oct 27, 2006, at 11:50 AM, Dan Nelson wrote:
MySQL is just giving you as much information as it can without
actually
running the query. It knows how it will go about running the query
(so
"type" is known absolutely), but it doesn't know exactly what it
will get
(so "rows" is only a gues
In the last episode (Oct 27), David Hillman said:
> On Oct 25, 2006, at 5:32 PM, Dan Buettner wrote:
> >My understanding of what is happening here is this:
> >
> >The 'rows' column of EXPLAIN output is an estimate of how many rows
> >MySQL thinks it will likely have to examine in a table to get you
On Oct 25, 2006, at 5:32 PM, Dan Buettner wrote:
My understanding of what is happening here is this:
The 'rows' column of EXPLAIN output is an estimate of how many rows
MySQL thinks it will likely have to examine in a table to get your
answer. When there's an index, it will hopefully be able to
My understanding of what is happening here is this:
The 'rows' column of EXPLAIN output is an estimate of how many rows
MySQL thinks it will likely have to examine in a table to get your
answer. When there's an index, it will hopefully be able to use that
to exmaine a small subset of the rows in
All;
Am I crazy, or doesn't this have to be an optimizer/explain bug?
SQL interspersed with comments follow...
mysql> CREATE TEMPORARY TABLE `table_a` ( `s_id` int(11) NOT NULL
default '0', `r_id` int(11) NOT NULL default '0', `d_id` int
(11) NOT NULL default '0', `status`
Hi,
When you have a table with more than 10 million rows, one row less or
one row more
shouldn't make a difference, right? ... Well, think again. Look at this
EXPLAIN statements,
it seems that the optimizer prefers a full table scan in the normal
query but uses the index
if there's a LIMIT *numb
On Tue, 2003-03-18 at 21:38, [EMAIL PROTECTED] wrote:
> Description:
>
> Hello Peter,
>
> Have you explained to Heikki this problem?
> Have you fixed it?
>
> Please, tell me about it.
>
Dear Rafarife,
This problem is qualified as wrong optimizer plan selection.
Happily yo
Description:
Hello Peter,
Have you explained to Heikki this problem?
Have you fixed it?
Please, tell me about it.
Regards,
Rafa
How-To-Repeat:
Select ... from giros ...
Fix:
-
Synopsis:optimizer bug in the index used by mysql/Inno
Description:
Hello Peter,
I have sent to ftp://support.mysql.com/pub/mysql/secret the table definition
and data (Giros.txt) in a compressed file named Giros.zip so you can
invetigate it.
You can see the following queries:
SELECT TIPO,DOC,NRE
FROM GIROS
WHERE (GIROS.TIPO
Description:
Hello Alexander,
You wrote:
>From EXPLAIN result output you can do only opposite conclusion: With InnoDB MySQL
>chooses
>to use Index TipoFeVCod for which it expects to match 9417 rows. This is about twice
>less
>rows than expected with PRIMARY key in second explain
Hello,
[EMAIL PROTECTED] wrote:
Description:
Hello,
I am working with mysql/InnoDb 4.0.11 under Windows 2000.
I have the following table:
Time: 0.20 secs.
Explain:
table type possible_keys keykey_len ref rows Extra
GIROS range PRI
Description:
Hello,
I am working with mysql/InnoDb 4.0.11 under Windows 2000.
I have the following table:
CREATE TABLE `giros` (
`Doc` varchar(10) NOT NULL default '',
`Tipo` char(1) NOT NULL default '',
`NRe` varchar(5) NOT NULL default '',
`FoP` char(2) N
--+--+---+
+
| albaranes | range | PRIMARY | PRIMARY | 8 | NULL | 44491 |
where u
sed |
+---+---+---+-+-+--+---+
+
1 row in set (0.00 sec)
- Original Message -
From: <[EMAIL PROTECTED]>
Newsgroups: mailing.database.mysql
Sent: Wednesday, October 09, 2002 1
t;[EMAIL PROTECTED]>
Sent: Wednesday, October 09, 2002 12:56 PM
Subject: optimizer bug in selecting fields that don´t belong to the index
used by mysql/Innodb
Description:
Hello,
We reported a problem about selecting fields that some of them didn´t
belong to
the used index on September.
We
Description:
Hello,
We reported a problem about selecting fields that some of them didn´t belong to
the used index on September.
We have already installed MySql 4.0.4 and we have a similar problem
(and also we are still having the original problem) when we select fields which some
Rafa,
- Original Message -
From: <[EMAIL PROTECTED]>
Newsgroups: mailing.database.mysql
Sent: Monday, September 23, 2002 10:54 AM
Subject: optimizer bug in selecting fields that don´t belong to the index
used by mysql/innodb
> Description:
> Hello,
>
> I wrote the
Description:
Hello,
I wrote the following text in my last message (It was an answer to Monty):
>Hello,
> Monty
> I have already sent to pub/mysql/secret the table definition and data
(clientes.txt)
> and my.ini file in a compressed file named clientes.zip.
> You
Date: Wed, 18 Sep 2002 05:46:39 -0400
From: [EMAIL PROTECTED]
InnoDB table
Select Cod,Nom,Nif,Nombre_comercial from Clientes Where (Nom = 'a2618' And
Cod>'059336') Or Nom>'a2618' Order by Nom ASC, Cod ASC Limit 50;
Time:0.08 secs.
Ha
Hi!
> "rafarife" == rafarife <[EMAIL PROTECTED]> writes:
rafarife> Description:
rafarife> Hi Heikki,
rafarife> I'm Lourdes and I work with Rafa in the MySQL project.
rafarife> We have done what you have told us. We have run SHOW STATUS before
rafarife> the query and we have obtained the
Description:
Hello Monty,
I have already sent to pub/mysql/secret the table definition and data (clientes.txt)
and my.ini file in a compressed file named clientes.zip.
You can import clientes.txt and test it.
I have only then problem with InnoDb tables.
I tell you my test
Hi!
> "rafarife" == rafarife <[EMAIL PROTECTED]> writes:
rafarife> Description:
rafarife> Hello,
rafarife> I am working with mysqld-max-nt under windows 2000 and unsing InnoDb
rafarife> tables.
rafarife> I have the following table:
rafarife>I don´t understa
Hi!
> "Heikki" == Heikki Tuuri <[EMAIL PROTECTED]> writes:
Heikki> Rafa,
Heikki> OR's are generally difficult to optimize.
Heikki, this is true if you are using OR on different keys.
MySQL can fully optimise the query when using OR on different key parts of the
same key (which is the case
Hi!
> "r" == rafarife <[EMAIL PROTECTED]> writes:
r>And now, the explain selects:
r> 1) Slow query
r> explain Select Cod,Nom,Nif,Nombre_comercial from Clientes
r> Where (Nom = 'GARCIA MANCILLA,S.L' And Cod>'061642')
r> Or Nom>'GARCIA MANCILLA,S.L' Order by Nom ASC, C
Description:
Heikki,
1) There is only one record with 'GARCIA MANCILLA,S.L'.
2) Mysql reported 53 scanned rows when I ran your mock-up query on your mock-up
table. This is ok.
3) I'm using mysql.exe client (sometimes I use front-end) and i don´t think it
removes the LIMIT 50
EMPORAL INNER JOIN CLIENTES ON TEMPORAL.COD=CLIENTES.COD;
(Inner join through the field cod, which is the primary index, so it's very fast).
Synopsis: optimizer bug in selecting fields that don´t belong to the index used by
mysql
Submitter-Id:
Originator: Rafa
Organization: Pecomark
My
Hi all,
>I gave not enough info about indexes. Use SHOW INDEX FROM table_name
sorry, now 2nd try with more info.
>> This bug was reported to fixed in 3.23.38.
>> But the mysql versions 3.23.49 and in 4.0.2
>> both look like as the bug is in them again.
>>
>> Example:
>> The following query
von,
Wednesday, July 31, 2002, 3:06:12 PM, you wrote:
vB> this bug was reported to fixed in 3.23.38.
vB> But the mysql vesions 3.23.49 and in 4.0.2
vB> both look like the bug is in them again.
vB> Example:
vB> The following query should use the index on
vB> dog.dog_timestamp_cr but uses fileso
Hi,
this bug was reported to fixed in 3.23.38.
But the mysql vesions 3.23.49 and in 4.0.2
both look like the bug is in them again.
Example:
The following query should use the index on
dog.dog_timestamp_cr but uses filesort instead.
mysql> EXPLAIN SELECT dog.dog_id, dog.dog_name, sire.dog_na
31 matches
Mail list logo
