Обсуждение: kill_prior_tuple for bitmap scan
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
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > 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, Really? An indexscan will release pin before returning no-more-tuples, and had better do so else we leak pins during queries involving many indexscans. (IIRC, I broke that around 7.3 :-() > 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. Not sure I believe that either. Even granting the assumption that the pages are still in cache, this implies a big increase in bufmgr traffic. This certainly is an interesting problem, but there is not a simple solution. regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> wrote > > Really? An indexscan will release pin before returning no-more-tuples, > and had better do so else we leak pins during queries involving many > indexscans. > I guess I see your point. For the scan stages not returning no-more-tuples, we can do kill, but the problem is that most bitmap index scan can finish in just one round :-(. > > Not sure I believe that either. Even granting the assumption that the > pages are still in cache, this implies a big increase in bufmgr traffic. > If you mean the bufmgr traffic is on the BufMappingLock, then I don't worry too much. Notice that we can have a list of buffer_ids that we are interested in, we can pin/recheck-buftag of these targets without asking bufmgr where are they. If we missed, then unpin and forget them is ok. Regards, Qingqing