From: Jeff Smelser Date: June 8 2005 2:13pm Subject: Re: Seriously.. When are we going to get subqueries?! List-Archive: http://lists.mysql.com/mysql/185160 Message-Id: <200506080913.39138.tradergt@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1308031.GS8gQiFnBe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1308031.GS8gQiFnBe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 June 2005 04:22 pm, Kevin Burton wrote: > Subqueries in 4.1 are totally broken. They don't use indexes. They're > evil. We're told we have subqueries but there's no way anyone on earth > could use them. To make matters worse a lot of developers are TRICKED > into using them and assume that mysql would do the right thing but its a > HUGE performance hit. Well, have you filed a bug? I just looked and didnt see one.. It wouldnt be= =20 the first time, however, a bug search function didnt find something that wa= s=20 there.. > So... > > 1. When will subqueries that actually use indexes be implemented? > We've been promised this feature since 4.0.... it was one of the biggest > feature wins of 4.1. > > 2. If they won't be in 5.0 could you please abandon a feature for 5.0 > and concentrate on subqueries? > > 3. If they won't be in 5.0 could you at least be honest and remove this > feature since in the best case its useless and in the worse case its > dangerous (god forbid someone should ship code that uses this)? > > Not trying to be obnoxious here but I really want this feature and the > current implementation is very...... evil. Well, your not helping anything ranting in here, filing a bug is the best w= ay=20 to get this fixed... Jeff --nextPart1308031.GS8gQiFnBe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCpv0ToOk9EvUvEtgRApN7AKCAziucb66C75kNhvRV0aboHrUwQgCgk6tI ime9sH4o1EapPhMVgOVBJS8= =xFt+ -----END PGP SIGNATURE----- --nextPart1308031.GS8gQiFnBe--