Re: should we set hint bits without dirtying the page? - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: should we set hint bits without dirtying the page?
Date
Msg-id 4CF83778.9030400@agliodbs.com
Whole thread Raw
In response to should we set hint bits without dirtying the page?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: should we set hint bits without dirtying the page?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.  Also, autovacuum would have no way of
knowing which pages are frozen without reading them.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Another proposal for table synonyms
Next
From: Andrew Dunstan
Date:
Subject: Re: WIP patch for parallel pg_dump