Re: crash-safe visibility map, take three

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: crash-safe visibility map, take three
Дата
Msg-id 28879.1291137722@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: crash-safe visibility map, take three  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 30, 2010 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's ridiculous to claim that that "doubles the cost of VACUUM". �In the
>> worst case, it will add 25% to the cost of setting an all-visible bit on
>> a page where there is no other work to do. �(You already are writing out
>> the heap page and the VM page,

> True.

>> plus a WAL image of the heap page, so a

> False.  That is exactly what we are NOT doing now and what we must
> find a way to avoid doing.

I do not accept that argument.  You can't make an omelette without
breaking eggs, and the cost of index-only scans is going to be that
it costs more to get the visibility bits set in the first place.

But having said that, I wonder whether we need a full-page image for
a WAL-logged action that is known to involve only setting a single bit
and updating LSN.  Would omitting the FPI be any more risky than what
happens now (ie, the page does get written back to disk at some point,
without any image from which it can be rewritten if the write fails...)
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: crash-safe visibility map, take three
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: crash-safe visibility map, take three