Comments for The Rhodium Toad

Comment on Selecting random rows from a table by bla

bla — Fri, 15 Apr 2011 11:04:16 +0000

This can be done simplier using >= instead of =. You will always find some response even if initial random guess was non-existing ID. No need to generate more then needed in case we won’t hit any existing.

. select * from items
. where id >= (select floor(random() * (max_id - min_id + 1))::integer
. + min_id from (select max(id) as max_id,
. min(id) as min_id from items) s1 limit 1)
. limit 1;

Rows occuring after a big gap in ids can get picked up more frequent.

Would be nice to write somewhere that JS is required to comment.

Comment on Selecting random rows from a table by Frank Kim

Frank Kim — Thu, 09 Sep 2010 19:58:22 +0000

I needed a smart way of getting the next row from my PostgreSQL table and this was perfect!

Comment on The Rule Challenge by Andrew

Andrew — Tue, 22 Jun 2010 17:36:48 +0000

We’ve had more than the usual number of rules questions on IRC recently, at least that’s my impression; that would probably explain the multiple recent blog posts. (And I only wrote this one because someone on IRC bugged me about it.)

Comment on The Rule Challenge by Robert Young

Robert Young — Tue, 22 Jun 2010 12:30:56 +0000

I’m not principally a PostgreSQL folk, DB2 is my main squeeze, but I do follow it a bit. The whole rules thing is something only PG did, and that was Stonebraker’s doing. One would have to read up his rationale way back when. From what I can find, View support is the justification for using rules, since that is the only way to get it. There have been a few links from the PostgreSQL site to rule posts such as this recently. I wonder why rules have become a topic du jour?

The challenge as written isn’t provable; the counterexample is exhaustive enumeration of all non-trivial rules.

As to better, one of those linked posts asserts that triggers are better. I would agree with that.

Comment on The Rule Challenge by Andrew

Andrew — Tue, 22 Jun 2010 04:41:57 +0000

That is indeed the real question, but it’s one for another blog post rather than this one :-)

Comment on The Rule Challenge by Tom Lane

Tom Lane — Tue, 22 Jun 2010 03:43:46 +0000

Rules work all right for views (ie, ON SELECT DO INSTEAD SELECT cases). There’s no question that every other case sucks. The *real* question is how to do better?

Comment on Selecting random rows from a table by Andrew

Andrew — Sat, 29 Aug 2009 20:13:08 +0000

That’s not unbiased; some rows are more likely than others to be returned.

Comment on Selecting random rows from a table by Andrew

Andrew — Thu, 27 Aug 2009 16:51:31 +0000

If you don’t really care about insert performance, and you only need one (or a few) random rows at once you can do this:

ALTER TABLE x ADD COLUMN r DOUBLE PRECISION;
ALTER TABLE x ALTER COLUMN r SET DEFAULT random();
UPDATE x SET r = random() WHERE r IS NULL; — this will be slow
ALTER TABLE x ALTER COLUMN r SET NOT NULL;
CREATE INDEX i ON x(r); — also slow
ANALYZE x(r);

Then take a sample row quickly by running this:
SELECT * FROM x WHERE r >= (SELECT random()) ORDER BY r LIMIT 1;

I’m not sure if asking for more than one row in the LIMIT clause would be statistically sound or not. The “random” order is fixed, so whenever you land in an overlapping spot the sequence will be the same.

If you just need a few rows, you can UNION a few of those together, and that should be as random as you could care for.

Comment on Selecting random rows from a table by Joanmi

Joanmi — Fri, 17 Apr 2009 23:18:11 +0000

Tell it to my boss.

Sorry for the noise.

Regards.

Comment on Selecting random rows from a table by Andrew

Andrew — Fri, 17 Apr 2009 15:28:50 +0000

I don’t have much sympathy for people still using 7.4 (which is approaching EOL).

The optimization for min() and max() to use indexes was added in 8.2.