Re: Idea for getting rid of VACUUM FREEZE on cold pages - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date
Msg-id AANLkTikFDdmukPzoAT4m3LidN1pqGbo6Gt24mL3P1r5k@mail.gmail.com
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Tue, Jun 8, 2010 at 5:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> > Why not just have a separate flag for HEAP_XMIN_FROZEN, that way we can
>> > keep the xmin but also can see it is frozen?
>>
>> We could do that, but I think the point of this exercise is to reduce
>> I/O - specifically, I/O caused by anti-wraparound vacuums - and I'm
>> not clear how such a flag would help with that.
>
> Hmmm: You suggested a variant of this idea, so whatever reasoning was
> behind your suggestion would be shared here, surely?
>
> Tom has been saying we cannot freeze early because we need to keep
> xmins. I agree with that. This suggestion shows it is possible to freeze
> a tuple AND keep its xmin. So that removes the argument that we should
> freeze more aggressively (whenever we write the block) and can thus
> reduce longer term I/O costs.

OK, yes, I see what you're getting at now.  There are two possible
ways to do freeze the tuples and keep the xmin: we can either rely on
the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can
additionally have a HEAP_XMIN_FROZEN bit as you propose here.  I am
not sure which way is better.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: How about closing some Open Items?
Next
From: Simon Riggs
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages