Re: Why is vacuum_freeze_min_age 100m? - Mailing list pgsql-performance

From Robert Haas
Subject Re: Why is vacuum_freeze_min_age 100m?
Date
Msg-id 603c8f070908121649u2524a42dj750c3719ea897b3f@mail.gmail.com
Whole thread Raw
In response to Re: Why is vacuum_freeze_min_age 100m?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why is vacuum_freeze_min_age 100m?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
On Wed, Aug 12, 2009 at 5:57 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Yeah, I know, but feel like I'm being a bit naughty in using VACUUM
>> FREEZE -- the documentation says:
>
>> | Selects aggressive "freezing" of tuples. Specifying FREEZE is
>> | equivalent to performing VACUUM with the vacuum_freeze_min_age
>> | parameter set to zero. The FREEZE option is deprecated and will be
>> | removed in a future release; set the parameter instead.
>
>> So I figure that since it is deprecated, at some point I'll be setting
>> the vacuum_freeze_min_age option rather than leaving it at the default
>> and using VACUUM FREEZE in the nightly maintenance run.
>
> I might be mistaken, but I think the reason we're planning to remove the
> option is mainly so we can get rid of FREEZE as a semi-reserved keyword.
> The GUC isn't going anywhere.
>
> Anyway, the bottom line is what you said: fooling with this setting
> seems like something that's only needed by advanced users.

Someone had the idea a while back of pre-freezing inserted tuples in
the WAL-bypass case.

It seems like in theory you could have a background process that would
iterate through dirty shared buffers and freeze tuples
opportunistically before they are written back to disk, but I'm not
sure that it would really be worth it.

...Robert

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is vacuum_freeze_min_age 100m?
Next
From: Torsten Zühlsdorff
Date:
Subject: Re: Why is vacuum_freeze_min_age 100m?