kill_prior_tuple for bitmap scan

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: kill_prior_tuple for bitmap scan
Date: 2006-06-19 03:34:06
Message-ID: e755vn$edb$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-19 03:55:09 Re: kill_prior_tuple for bitmap scan
Previous Message Tom Lane 2006-06-19 03:07:41 Re: Rethinking stats communication mechanisms