Les <nagylzs@xxxxxxxxx> writes: > If I try to select a single unused block this way: > explain analyze select id from media.block b where nrefs =0 limit 1 > then it runs for more than 10 minutes (I'm not sure how long, I cancelled > the query after 10 minutes). Are you sure it isn't blocked on a lock? Another theory is that the index contains many thousands of references to now-dead rows, and the query is vainly searching for a live entry. Given that EXPLAIN thinks there are only about 2300 live entries, and yet you say the index is 400MB, this seems pretty plausible. Have you disabled autovacuum, or something like that? (REINDEX could help here, at least till the index gets bloated again.) You might think that even so, it shouldn't take that long ... but indexes on UUID columns are a well known performance antipattern. The index entry order is likely to have precisely zip to do with the table's physical order, resulting in exceedingly-random access to the table, which'll be horribly expensive when the table is so much bigger than RAM. Can you replace the UUID column with a simple serial (identity) column? > I believe it is not actually using the index, because reading a single > (random?) entry from an index should not run for >10 minutes. You should believe what EXPLAIN tells you about the plan shape. (Its rowcount estimates are only estimates, though.) regards, tom lane
