On Mon, 2007-11-05 at 22:45 +0000, Heikki Linnakangas wrote: > > 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.
The thought crossed my mind, but I couldn't think of any reason that would need to be logged. Of course you're right, and the comments explain it well. > 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. > Wouldn't that still require WAL traffic? Otherwise how can you guarantee that the FrozenXid hits disk before TruncateCLOG truncates the old xmin away? Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend