I'm wondering why --- doesn't seem like it should take 6400msec to fetch
646 rows, unless perhaps the data is just horribly misordered relative
to the index. Which may in fact be the case ...
Hmm, actually I still don't understand why it takes 6400 ms to fetch the
rows. As far as I can see the index used is "covering" so that real row
lookups shouldn't be necessary. Also, only the the random_numbers
induces by questions with status = 1 should be considered - and this
part is a relatively small subset.
In general, I don't understand why the query is so I/O dependant as it
apparently is.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
