> 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.
