Comments on: Pseudo Reverse Indexes in MySQL http://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in-mysql/ A goal is a dream with a deadline. Fri, 12 Mar 2010 13:16:50 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Ilya Grigorik http://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in-mysql/comment-page-1/#comment-62285 Ilya Grigorik Thu, 23 Aug 2007 03:09:47 +0000 http://www.igvita.com/blog/2007/08/20/pseudo-reverse-indexes-in-mysql/#comment-62285 Mike, good point! I just ran a quick test, and everything seems to be a-ok: <blockquote>select timestampdiff(SECOND, '2050-01-01','2035-01-01'); >> -473385600</blockquote> Dustin, that's what I was thinking too! I was honestly surprised to find this limitation in place. Then again, could this be one of these 'any DBA will know type gotchas'? Peter, thanks for the tip on meta tables. I might have to reconsider our current table structure, and I'll keep that in mind. I guess the only way to learn these things is with experience! Mike, good point! I just ran a quick test, and everything seems to be a-ok:

select timestampdiff(SECOND, ‘2050-01-01′,’2035-01-01′);
>> -473385600

Dustin, that’s what I was thinking too! I was honestly surprised to find this limitation in place. Then again, could this be one of these ‘any DBA will know type gotchas’?

Peter, thanks for the tip on meta tables. I might have to reconsider our current table structure, and I’ll keep that in mind. I guess the only way to learn these things is with experience!

]]> By: Peter Cooper http://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in-mysql/comment-page-1/#comment-61942 Peter Cooper Tue, 21 Aug 2007 22:33:28 +0000 http://www.igvita.com/blog/2007/08/20/pseudo-reverse-indexes-in-mysql/#comment-61942 Interesting hack! I'll be sure to give this a try if it comes up as an issue in future. It didn't happen with Feed Digest, despite a bigger data set, because quite early on I split the data set up into a meta table with VERY light rows, and then a table with the actual data. So the ORDER BY / GROUP BY stuff all takes place on the meta, then the IDs from that are used to load the real data from elsewhere. This solves so many problems as each row can be a fixed width (about 20 bytes I think at the moment). The main reason for this solution was due to constant creation of temporary tables after we reached a million or so entries. With the meta table, it works smoothly up into the tens of millions. Interesting hack! I’ll be sure to give this a try if it comes up as an issue in future. It didn’t happen with Feed Digest, despite a bigger data set, because quite early on I split the data set up into a meta table with VERY light rows, and then a table with the actual data. So the ORDER BY / GROUP BY stuff all takes place on the meta, then the IDs from that are used to load the real data from elsewhere. This solves so many problems as each row can be a fixed width (about 20 bytes I think at the moment). The main reason for this solution was due to constant creation of temporary tables after we reached a million or so entries. With the meta table, it works smoothly up into the tens of millions.

]]> By: Dustin Puryear http://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in-mysql/comment-page-1/#comment-61909 Dustin Puryear Tue, 21 Aug 2007 20:21:40 +0000 http://www.igvita.com/blog/2007/08/20/pseudo-reverse-indexes-in-mysql/#comment-61909 Very interesting. I have to wonder why this doesn't come up more often if large sites that rely on MySQL, at least for *some* of their services, must be hitting the same limitations, e.g., Yahoo Finance? -- Dustin Puryear Author, <a href="http://www.puryear-it.com/pubs/linux-unix-best-practices" rel="nofollow">Best Practices for Managing Linux and UNIX Servers</a> <a href="http://www.puryear-it.com" rel="nofollow">http://www.puryear-it.com</a> Very interesting. I have to wonder why this doesn’t come up more often if large sites that rely on MySQL, at least for *some* of their services, must be hitting the same limitations, e.g., Yahoo Finance?

–
Dustin Puryear
Author, Best Practices for Managing Linux and UNIX Servers
http://www.puryear-it.com

]]> By: Mike Woodhouse http://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in-mysql/comment-page-1/#comment-61625 Mike Woodhouse Mon, 20 Aug 2007 21:20:49 +0000 http://www.igvita.com/blog/2007/08/20/pseudo-reverse-indexes-in-mysql/#comment-61625 I don't think the date chosen should matter particularly, provided that negative integers are indexed the same as positive ones. And assuming that timestampdiff will return a negative number by 2035, if it doesn't already. If so, you should be good until 999999999 seconds after 01/01/2035, or another 31 years or so. By which time I hope we'll all be around to still care. I don’t think the date chosen should matter particularly, provided that negative integers are indexed the same as positive ones. And assuming that timestampdiff will return a negative number by 2035, if it doesn’t already.

If so, you should be good until 999999999 seconds after 01/01/2035, or another 31 years or so. By which time I hope we’ll all be around to still care.

]]>