At 17:06 -0400 6/23/04, Alejandro Heyworth wrote:
That could be. If so, it's a MySQL 3.23 limitation that was fixed in
MySQL 4.0.
So, what we are agreeing on is that MySQL 4.x does in fact support
both DESC and ASC indexes?
No, what we're saying is that in 3.23, MySQL did not efficiently traverse
indexes in reverse order for ORDER BY DESC. In 4.0 and up, indexes
are still stored in ascending order, but the server now traverses
them efficiently in reverse order for DESC sorts.
If this is the case and we're doing something wrong here, cool!
I definitely think the docs should reflect this functionality!
No need, because it's still true that DESC is ignored for index specifications.
BUT,
ALTER TABLE kneejoint ADD INDEX testindex (compression DESC);
1) SHOW INDEX kneejoint only shows ASC collation.
Correct.
2) SELECT compression FROM kneejoint still returns values in ASC order.
No. It returns them in an undefined order if you don't use ORDER BY.
It may happen to look like ASC order.
We are currently using the 4.1.2 binaries (MyISAM) and the DESC
index functionality isn't working for us yet.
I hear all of your comments on the actual storage of the data and
understand that. However, the indexes should return values in the
proper indexed order if the indexes are being used and they are.
Our experience is that ORDER BY ___ ASC on an ASC index is faster
than an ORDER BY DESC on the same ASC index when the data sets are
large.
Thanks for the help by the way! We are rapidly migrating our
experiments to MySQL and trying to dump SQL Server forever!
--
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
