Thread: 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