Re: opportunistic tuple freezing

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: opportunistic tuple freezing
Date: 2009-08-17 02:43:47
Message-ID: 407d949e0908161943l36e9a7dbj1f8dfa07ce0be43e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 17, 2009 at 2:32 AM, Jeff Davis<pgsql(at)j-davis(dot)com> wrote:
>
> 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.

I thought Josh's idea to apply this opportunistic threshold if the
page is already dirty for any reason was a good idea. Ie, if some
other dml or hint bit was set since the page was loaded even if vacuum
doesn't find any tuples are freezable.

So basically I think the logic should be:

normal-vacuum-processing
if (page-is-clean)
try-to-freeze(normal-threshold)
if (page-is-dirty)
try-to-freeze(opportunistic-threshold)

Sure it's duplicated work but I don't think it will add up to much.
The normal pass could remember the oldest xid found and we could skip
the second pass if the oldest xid is still too young.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-08-17 03:01:22 Re: opportunistic tuple freezing
Previous Message Itagaki Takahiro 2009-08-17 01:53:46 Encoding issues in console and eventlog on win32