Re: Set visibility map bit after HOT prune

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Set visibility map bit after HOT prune
Date: 2012-12-16 16:40:53
Message-ID: 20121216164053.GG4683@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-12-16 16:25:03 +0000, Simon Riggs wrote:
> On 16 December 2012 14:41, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-12-16 16:44:04 Re: logical decoding - GetOldestXmin
Previous Message Tomas Vondra 2012-12-16 16:38:09 Re: Serious problem: media recovery fails after system or PostgreSQL crash