> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
