Re: Visibility map thoughts

Jeff Davis wrote:
> On Mon, 2007-11-05 at 09:52 +0000, Heikki Linnakangas wrote:
>> It's not useful for VACUUM FREEZE, unless we're willing to freeze much
>> more aggressively, and change the meaning of a set bit to "all tuples on
>> heap page are frozen".
>
> This means that a regular VACUUM will no longer be enough to ensure
> safety from transaction id wraparound.

Good point. So we'd still need regular VACUUMs every now and then.

(Gosh, we really need a name for the sort of vacuum. I was about to say
"we'd still need regular regular VACUUMs" :-))

> I don't think this will be hard to fix, but it's an extra detail that
> would need to be decided. The most apparent options appear to be:
>
> 1) Do as you say above. What are some of the cost trade-offs here? It
> seems that frequent VACUUM FREEZE runs would keep the visibility map
> mostly full, but will also cause more writing. I suppose the worst case
> is that every tuple write needs results in two data page writes, one
> normal write and another to freeze it later, which sounds bad. Maybe
> there's a way to try to freeze the tuples on a page before it's written
> out?

It would also create more WAL traffic, because freezing tuples needs to
be WAL-logged.

> 2) Change to autovacuum to FREEZE on the forced autovacuum to prevent
> wraparound.

Doesn't necessarily need to be a VACUUM FREEZE. Just a "regular VACUUM"
instead of using the visibility map.

> 3) Use multiple bits per visibility map

That would work.

> 4) Have multiple types of visibility maps

I'd rather not do that. It starts to get more complex and more expensive
to update.

5) Have a more fine-grain equivalent of relfrozenxid. For example one
frozenxid per visibility map page, so that whenever you update the
visibility map, you also update the frozenxid. To advance the
relfrozenxid in pg_class, you scan the visibility map and set
relfrozenxid to the smallest frozenxid. Unlike relfrozenxid, it could be
set to FrozenXid if the group of pages are totally frozen.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com