Comments on: Getting a random row from a relational database

By: Sym Roe

Sym Roe — Sun, 04 Apr 2010 19:47:47 +0000

Yes, I understand it’s not “random”, however, your method will exclude some rows entirely! :)

The best solution I’ve seen to this is to store all IDs (and maybe some other data) in redis and use its fast random ordering. That adds more complexity, but if true random ordering is important then it seems about the only way.

By: Emil Vladev

Emil Vladev — Sun, 04 Apr 2010 19:38:57 +0000

@Sym: Correct, but if you have “holes” in the PKs some of the keys have higher chance to be picked up, so it’s not completely random. Nevertheless, it’s a good compromise.

By: Sym Roe

Sym Roe — Sun, 04 Apr 2010 19:10:29 +0000

Using COUNT wont work if you have a lot of deleted rows in the middle of the table.

I would grab the highest PK (SELECT pk/ORDER BY py ASC/LIMIT 1), then get a random number in that range, then get the offset row, like above.

That way you’ll always get a row in the range of 0 and the highest PK.

Also, it would be faster in postgres :)

By: Saiyine

Saiyine — Sun, 24 Jan 2010 23:50:21 +0000

I’ve done the tests myself, and I can confirm your results.

Statistics on getting a random row from a table:
http://www.saiyine.com/post.901.php

By: Emil Vladev

Emil Vladev — Sun, 24 Jan 2010 10:24:58 +0000

@TheQuux: Thanks for the clarification. About ORDER BY RAND() in PostgreSQL being the same – this is not right. ORDER BY RAND() will have to generate a second copy of the table, sort it and then return a record, while SELECT COUNT(*) will need to check the rows but that’s about it. If you have a better method I would love to here it – this one is far from perfect.

By: TheQuux

TheQuux — Sun, 24 Jan 2010 06:05:42 +0000

@emil: Count(*) and Count(column) are actually different.

SELECT COUNT(*) FROM table;

gives you the number of rows in table, whereas

SELECT COUNT(column) FROM table;

is equivalent to:

SELECT COUNT(*) FROM table WHERE column IS NOT NULL;

So, the first would be fast if your database keeps track of the number of rows in the table, whereas the second would need to consult an index or actually run a sequential scan over the table. Incidentally, figuring out how many rows are in the table with PostgreSQL takes right about as long as the initial “select * from table order by rand() limit 1″, so it doesn’t leave you any better off.

By: Emil Vladev

Emil Vladev — Sat, 23 Jan 2010 20:23:22 +0000

@Travis: In my experience there is no real difference between both – databases usually optimize COUNT(*) (I think that in MyISAM the row number is stored with the table and is not computed)

@Saiyine: Even with one query the difference is evident.

By: Saiyine

Saiyine — Sat, 23 Jan 2010 19:54:36 +0000

Don’t you think a benchmark with just one query it’s a bit naive? What about doing it with a thousand querys?

By: Travis L

Travis L — Sat, 23 Jan 2010 19:32:12 +0000

In your solution, part 1, you do a SELECT COUNT(*) rather than SELECT COUNT( col_name )? I’ve always believed that COUNT(*) is slower than counting 1 column.