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

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: should we set hint bits without dirtying the page?
Date: 2010-12-03 00:19:04
Message-ID: 4CF83778.9030400@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-12-03 00:21:28 Re: WIP patch for parallel pg_dump
Previous Message Alvaro Herrera 2010-12-03 00:17:07 Re: Another proposal for table synonyms