opportunistic tuple freezing - Mailing list pgsql-hackers

From Jeff Davis
Subject opportunistic tuple freezing
Date
Msg-id 1250472759.23986.75.camel@jdavis
Whole thread Raw
Responses Re: opportunistic tuple freezing  (Greg Stark <gsstark@mit.edu>)
Re: opportunistic tuple freezing  (Greg Stark <gsstark@mit.edu>)
Re: opportunistic tuple freezing  (Peter Eisentraut <peter_e@gmx.net>)
Re: opportunistic tuple freezing  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Attached is a patch to implement the idea discussed here:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01137.php

If VACUUM freezes one tuple on a page, it's likely that there are others
on the same page that are close to vacuum_freeze_min_age, but not quite.
Because the page is already dirty from freezing one tuple, it makes
sense to be more aggressive about freezing the rest, in the hope that
all the tuples will be frozen, and we will not have to dirty the page
again later.

This patch introduces a GUC vacuum_freeze_opportunistic_ratio. If one
tuple on a page is frozen by vacuum, it effectively multiplies
vacuum_freeze_min_age by vacuum_freeze_opportunistic_ratio and uses that
lower (more aggressive) value only for the current page.

The reason we don't just freeze all the tuples we can (effectively
setting the vacuum_freeze_opportunistic_ratio to zero) is to preserve
transaction ID information for diagnosing problems.

Regards,
    Jeff Davis

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Croatian translation
Next
From: Itagaki Takahiro
Date:
Subject: Encoding issues in console and eventlog on win32