7 messages in com.mysql.lists.bugsRe: [mysql 4.0.14-nt] MySQL eats my C...
FromSent OnAttachments
Frank Schönheit08 Aug 2003 08:58 
Alexander Keremidarski08 Aug 2003 12:41 
Frank Schönheit08 Aug 2003 14:08 
Alexander Keremidarski08 Aug 2003 16:51 
Frank Schönheit09 Aug 2003 05:42 
Alexander Keremidarski10 Aug 2003 15:08 
Frank Schönheit10 Aug 2003 23:55 
Subject:Re: [mysql 4.0.14-nt] MySQL eats my CPU with speical SELECT statement
From:Frank Schönheit (fran@gmx.de)
Date:08/08/2003 02:08:30 PM
List:com.mysql.lists.bugs

Hello alexander,

thanks for your quick reply - see my comments below ...

We will investigate this case, but Query in question is Cartesian Product
between 3 tables!

... 305*3638*231 = 256315290

(quite impressing arithmetics, indeed :)

Query which will provide 256 million rows and which can store them in some temporary space before sending to client will be always slow.

Ah, yes ... looking at the (wrongly generated) statement, again:

SELECT `artists`.`name`, `albums`.`name` FROM `albums`, `tracks`, `artists` GROUP BY `tracks`.`al_id` HAVING 0 = 1

... Being *that* used to seeing "WHERE 0 = 1" in OOo-generated statements, I didn't realize that we're talking about a HAVING here, which of course is a different thing.

I don't agree with you about "closing as INVALID, because it's an MySQL bug."

You're completely right, sorry for sueing MySQL! This, indeed, is an amount of data which the next 4 generations of my PC won't be able to handling easily :).

I'll state this in the IZ-issue (citing you there :), and reopen it.

This is very good example of careless SQL usage. No matter if this query is written by hand or generated by some programs.

Generated by OOo in this case, unfortunately :(. I already submitted an issue for this improper generation, before I asked here, but as said: reading the HAVING as WHERE didn't let me realized that it's also the real problem. Sorry!

Do you agree with me this is not a bug really?

Yes!

Thanks & Ciao Frank