Re: Set visibility map bit after HOT prune - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Set visibility map bit after HOT prune
Date
Msg-id 20121216164053.GG4683@awork2.anarazel.de
Whole thread Raw
In response to Re: Set visibility map bit after HOT prune  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 2012-12-16 16:25:03 +0000, Simon Riggs wrote:
> On 16 December 2012 14:41, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2012-12-16 13:23:56 +0530, Pavan Deolasee wrote:
> >> Another idea could have been to NOT clear the visibility bit when a
> >> HOT update happens. Such tuple can get pruned by HOT prune, so we
> >> don't need vacuum per se, and the index-only scans are not affected
> >> because the update was a HOT update, so the index keys did not change
> >> either. So index-only scans would continue to return the same result.
> >> Don't know if this would work with hot standby, probably not.
> >
> > For IOSs that sounds like an interesting and itself easy to implement
> > idea, you basically only would need to add a single !use_hot_update in
> > the if blocks doing the PageClearAllVisible in heap_update.
> > This probably could make IOSs far more likely in some scenarios.
>
> Doing that would completely change the meaning of the visibility map
> from a heap visibility map into an index-only map.
>
> IndexOnly scans would still work, but nothing else would ever and it
> would be hard to confirm the validity of the vm.

I don't think it would change the meaning that much - the visibilitymap
would still work for vacuum as normal heap updates would still unset the
all-visible flag. Vacuum would skip pages that already were all-visible
and then only got hot updated, true, but that seems like its an
acceptable tradeoff as that dead space can be fully cleaned up by hot
pruning.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Serious problem: media recovery fails after system or PostgreSQL crash
Next
From: Simon Riggs
Date:
Subject: Re: logical decoding - GetOldestXmin