Re: should we set hint bits without dirtying the page?

On Thu, Dec 2, 2010 at 7:19 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 12/2/10 4:00 PM, Robert Haas wrote:
>> As soon as all tuples on the page are all-visible, VACUUM will freeze
>> every tuple on the page (setting a HEAP_XMIN_FROZEN bit rather than
>> actually overwriting XMIN, to preserve forensic information) and mark
>> it all-visible in a single WAL-logged operation.  Also, we could have
>> the background writer (!) try to perform this same operation on pages
>> evicted during the cleaning scan.  This would impose the same sort of
>> I/O cap as the previous idea, although it would generate not only page
>> writes but also WAL activity.
>
> I would love this.  It would also help considerably with the "freezing
> already cold data" problem ... if we were allowed to treat the frozen
> bit as canonical and not update any of the tuples.  While never needing
> to touch pages at all for freezing is my preference, updating them while
> they're in memory anyway is a close second.
>
> Hmm.  That doesn't work, though; the page can contain tuples which are
> attached to rolledback XIDs.

Sure, well, any pages that are not all-visible will need to get
vacuumed before they get marked all-visible. I can't fix that
problem. But the more we freeze opportunistically before vacuum, the
less painful vacuum will be when it finally kicks in. I don't
anticipate this is going to be perfect; I'd be happy if we could
achieve "better".

> Also, autovacuum would have no way of
> knowing which pages are frozen without reading them.

Well, reading them is still better than reading them and then writing
them. But in the long term I imagine we can avoid even doing that
much. If we have a crash-safe visibility map and an aggressive
freezing policy that freezes all tuples on the page before marking it
all-visible, then even an anti-wraparound vacuum needn't scan
all-visible pages. We might not feel confident to rely on that right
away, but I think over the long term we can hope to get there.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company