> That would spare a HashAggregate and an index scan. The index scan would > very likely not be a problem, as the same index entries are visited in > the subquery and likely are cached, and the HashAggregate should be also > fast for the max 1000 rows it has to handle, but they are still > completely unnecessary for my purpose, so I still think the LIMIT on > DELETE and UPDATE would make perfect sense. Oh, it just occured to me: the subquery is using a different index than the outer loop, so we can forget about caching. Considering that the outer loop uses an index 10x bigger than the subquery, and that means ~50million entries, and the typical situation where this would be used mostly selects 1000 rows indeed, the LIMIT on DELETE for this case would mean for sure ~ 50% speedup. Cheers, Csaba.
