Heikki Linnakangas <heikki@enterprisedb.com> wrote:
> > We use 1 bit per block, so we cannot separate pages that need either
> > vacuum or freeze only. The reason is that we cannot determine where to
> > record before/after updated tuples. If the transaction is commited,
> > before-version should be recorded into needs-vacuum bitmap and
> > after-version into needs-freeze bitmap. But on rollback, it is inverted.
> > We cannot judge which we should do until the end of transaction.
>
> Yeah, that makes the DSM less useful. Are you thinking of freezing more
> aggressively because of that? Or doing a full-scanning vacuum every now
> and then to freeze?
I recommend to use VACUUM FREEZE with the patch, but what you say is
surely reasonable. I think that backends record all of the changes into
1st bitmap, and then, VACUUM moves some bits from 1st bitmap to 2nd one.
Assumimg we had two bitmaps; (1)invisible-from-someone-bitmap and
(2)freeze-needed-bitmap. (Actually, two bits would be packed into one
compound bitmap, but for illustrative purposes.)
We have to record changes into (1) at first, because we can find a page
needs either VACUUM or FREEZE only after commits or rollbacks.
VACUUM scans pages using (1). Newly inserted pages are also scanned at
first vacuum, even if they requires only freeze. If the vacuum find that
all of tuples in a page are vacuumed completely and old enough to be
visible by all open transactions, delete the page from (1). Then, all are
also frozen, the page is not in both bitmaps. Otherwise, put it into (2).
We can use (1) for the index only scanning, because all of the tuples not
recorded in (1) are visible to all backends, regardless of whether they
are also recorded in (2).
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center