Re: Set visibility map bit after HOT prune

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Andres Freund <andres(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:25:03
Message-ID: CA+U5nML1aXONK52X8TO5S6Z3NDJOEEGsexS1GKq96V7tPduFLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

-1

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2012-12-16 16:38:09 Re: Serious problem: media recovery fails after system or PostgreSQL crash
Previous Message Pavan Deolasee 2012-12-16 15:27:09 Re: Set visibility map bit after HOT prune