As I read, the kill_prior_tuple optimization doesn't work for bitmap scan
code. To fix this problem, we have two choices.
One is still use the kill_prior_tuple trick in a modified way. Heap TIDs
recycling should not be a problem. This is because generally we always hold
pin of the last index page we scanned, so the vacuum has to wait and the
underlying heap can't get vaccummed. Another smaller problem is that we have
to scan the heap pages again to identify the index pointers, but that's
affordable since these pages should be in the buffer pool with big chance.
An alternative way might leave the job to autovacuum -- once we found bitmap
scan seeing a lot of dead tuples, notify it to do the job. But this doesn't
look interesting -- the autovacuum performs in a coarse and blind level and
cause a lot of CPUs/IOs.
Anyway, it is a performance lost on a frequently updated table if we do
nothing. I observed in a optimized OLTP server for 7.4 using index scan
experienced a performance problem due to the plan changed to bitmap index
scan.
Is there any show-stop reasons that we don't do either of them?
Regards,
Qingqing
