Re: opportunistic tuple freezing - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: opportunistic tuple freezing
Date
Msg-id 1250483193.24704.42.camel@jdavis
Whole thread Raw
In response to Re: opportunistic tuple freezing  (Greg Stark <gsstark@mit.edu>)
List 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: build error
Next
From: Jeff Davis
Date:
Subject: Re: WIP: generalized index constraints