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
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 |