Comments on: Descending indexing and loose index scan http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/ Everything about MySQL Performance Fri, 05 Dec 2008 09:21:14 +0000 http://wordpress.org/?v=2.5.1 By: Pseudo Reverse Indexes in MySQL - igvita.com http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-319320 Pseudo Reverse Indexes in MySQL - igvita.com Sun, 29 Jun 2008 04:45:03 +0000 http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-319320 [...] clause, surely the SQL server will be smart enough to read the index backwards. And in fact, you're mostly right. There is a hit on performance, but it's not a show-stopper for most datasets. The caveat: most [...] [...] clause, surely the SQL server will be smart enough to read the index backwards. And in fact, you’re mostly right. There is a hit on performance, but it’s not a show-stopper for most datasets. The caveat: most [...]

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-243 peter Thu, 22 Jun 2006 14:00:16 +0000 http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-243 Gabe, Yes you can use id*-1 if id is signed or max_int-id for unsigned ids If you really need sorting by multiple fields in different directions this is perhaps best solution. Gabe,

Yes you can use id*-1 if id is signed or max_int-id for unsigned ids

If you really need sorting by multiple fields in different directions this is perhaps best solution.

]]> By: Gabe http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-241 Gabe Thu, 22 Jun 2006 04:59:33 +0000 http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-241 Thanks, What is your suggestion as to the way to create the reverse_id field? just (-1)* the id number? Or is there a better/more practical way you've found. Thanks again for the response, Gabe Thanks,
What is your suggestion as to the way to create the reverse_id field? just (-1)* the id number? Or is there a better/more practical way you’ve found.
Thanks again for the response,
Gabe

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-235 peter Wed, 21 Jun 2006 12:57:22 +0000 http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-235 Gabe, It is not entirely clear from the query which columns correspond to which of the tables, which affect how you whould optimize query dramatically. It is important sorting is done by fields from first tables. In your case if sorting is done by fields from "ad" table, key (scraped,siteid) is optimal solution for "asc" sort but if you need to have reverse sort you need to have something like reverse_timestamp hack. I googled a bit about reverse_timestamp and it looks Wikipedia was using it for a bit different purpose, this is why they do not need it any more. In MySQL before 4.0 WHERE key_part1=const ORDER BY key_part2 DESC simply was not optimized even if you're sorting by single column. In MySQL 4.0 this problem is fixed and so Wikipedia did not need hack any more. However if you want to sort by two columns in different order you still need this kind of hack. So in your case order by scraped desc,siteid desc should also be fast, while order by scraped desc,siteid asc should be slow. Gabe,

It is not entirely clear from the query which columns correspond to which of the tables, which affect how you whould optimize query dramatically. It is important sorting is done by fields from first tables. In your case if sorting is done by fields from “ad” table, key (scraped,siteid) is optimal solution for “asc” sort but if you need to have reverse sort you need to have
something like reverse_timestamp hack.

I googled a bit about reverse_timestamp and it looks Wikipedia was using it for a bit different purpose, this is why they do not need it any more. In MySQL before 4.0 WHERE key_part1=const ORDER BY key_part2 DESC simply was not optimized even if you’re sorting by single column. In MySQL 4.0 this problem is fixed and so Wikipedia did not need hack any more. However if you want to sort by two columns in different order you still need this kind of hack.

So in your case order by scraped desc,siteid desc should also be fast, while order by scraped desc,siteid asc should be slow.

]]> By: Gabe http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-230 Gabe Tue, 20 Jun 2006 16:02:04 +0000 http://www.mysqlperformanceblog.com/2006/05/09/descending-indexing-and-loose-index-scan/#comment-230 Hey, I'm doing the following SQL query on a 150k entry table: explain select * from ad STRAIGHT JOIN category ON catid=sitecatid order by scraped asc,siteid asc limit 0,20; How would you suggest doing the keys on scraped and siteid? If I do order by scraped asc, siteid asc it goes very fast, because I have an index on (scraped,siteid), but as of MySQL 5.0.21 there is no descending index possible, so how would you suggest I manage the descending index? I noticed you mentioned the reverse_timestamp hack in wikipedia, but that is apparently no longer in use, which means maybe there is a better way then creating a 'negative value' column or something that I could sort ASC, but would effectively be DESC. Thanks, Gabe Hey,
I’m doing the following SQL query on a 150k entry table:
explain select * from ad STRAIGHT JOIN category ON catid=sitecatid order by scraped asc,siteid asc limit 0,20;
How would you suggest doing the keys on scraped and siteid? If I do order by scraped asc, siteid asc it goes very fast, because I have an index on (scraped,siteid), but as of MySQL 5.0.21 there is no descending index possible, so how would you suggest I manage the descending index? I noticed you mentioned the reverse_timestamp hack in wikipedia, but that is apparently no longer in use, which means maybe there is a better way then creating a ‘negative value’ column or something that I could sort ASC, but would effectively be DESC.
Thanks,
Gabe

]]>