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