Re: opportunistic tuple freezing

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: opportunistic tuple freezing
Date: 2009-08-17 04:26:33
Message-ID: 1250483193.24704.42.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2009-08-17 at 03:43 +0100, Greg Stark wrote:
> I thought Josh's idea to apply this opportunistic threshold if the
> page is already dirty for any reason was a good idea.

Is there a good way to tell if a buffer is dirty or not?

I don't see an exported function to do that. I could check by looking at
the flags directly, but I don't see that being done in any file that
doesn't have the word "buf" in it, so I assume it's breaking an
abstraction.

> 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.

For this patch, I think this optimization might be useful, but I don't
see how it would be important. The primary optimization in my patch is
that VACUUM is likely to freeze all of the xids on a page at once.

Hint bits are likely to be set before the tuples are eligible for
freezing (unless the new GUC is set close to zero), and assorted dml is
likely to mean that there are still non-freezable xids on the page
(meaning that we still need to write it again, anyway).

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-08-17 05:26:20 Re: WIP: generalized index constraints
Previous Message Andrew Dunstan 2009-08-17 04:05:55 Re: build error