Re: crash-safe visibility map, take three - Mailing list pgsql-hackers

From Tom Lane
Subject Re: crash-safe visibility map, take three
Date
Msg-id 28879.1291137722@sss.pgh.pa.us
Whole thread Raw
In response to Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: crash-safe visibility map, take three
Re: crash-safe visibility map, take three
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: crash-safe visibility map, take three
Next
From: Heikki Linnakangas
Date:
Subject: Re: crash-safe visibility map, take three