Re: Idea for getting rid of VACUUM FREEZE on cold pages

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Idea for getting rid of VACUUM FREEZE on cold pages
Дата
Msg-id 26093.1276099776@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But none of this accomplishes a damn thing towards the original goal,
>> which was to avoid an extra disk write associated with freezing (not
>> to mention an extra write for setting the transaction-committed hint
>> bit). �Setting a bit is no cheaper from that standpoint than changing
>> the xmin field.

> Except for insert-only tables, I don't believe this is true.

But insert-only tables are exactly the case that Josh complained about
to start with.

> If you
> freeze all tuples by the time the pages are marked all-visible,
> perhaps via the xmin-preserving mechanism Simon suggested, then you
> can use the visibility map to skip anti-wraparound vacuum as well as
> regular vacuum.  That sounds to me like it's accomplishing something.
> Is it a complete solution? No.  Is it better than what we have now?
> Yes.

I do like the idea of using a status bit rather than FrozenXid to mark a
frozen tuple, because that eliminates the conflict between wanting to
freeze aggressively for performance reasons and wanting to preserve Xids
for forensic reasons.  But it doesn't seem to do much for Josh's
original problem.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: hstore ==> and deprecate =>
Следующее
От: rupendra.chulyadyo@gmail.com
Дата:
Сообщение: Performance of Bit String