From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Visibility map thoughts |
Date: | 2007-11-06 17:19:14 |
Message-ID: | 1194369554.22428.177.camel@dogma.ljc.laika.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2007-11-06 17:43:30 | Re: Fix pg_dump dependency on postgres.h |
Previous Message | Peter Eisentraut | 2007-11-06 17:16:09 | Re: Weird type selection choice |