Re: Visibility map thoughts - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Visibility map thoughts
Date
Msg-id 472F9D0D.4050106@enterprisedb.com
Whole thread Raw
In response to Re: Visibility map thoughts  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Visibility map thoughts  ("Marko Kreen" <markokr@gmail.com>)
Re: Visibility map thoughts  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Mark Wong"
Date:
Subject: Re: Test lab
Next
From: Rick Gigger
Date:
Subject: Re: should I worry?