Re: Why is vacuum_freeze_min_age 100m?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Why is vacuum_freeze_min_age 100m?
Дата
Msg-id 603c8f070908121649u2524a42dj750c3719ea897b3f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why is vacuum_freeze_min_age 100m?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why is vacuum_freeze_min_age 100m?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why is vacuum_freeze_min_age 100m?
Следующее
От: Torsten Zühlsdorff
Дата:
Сообщение: Re: Why is vacuum_freeze_min_age 100m?