Re: Set visibility map bit after HOT prune

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.

The complicated bit seems to be the heapgetpage() logic arround
all_visible, because HOT updates are obviously relevant in normal heap
scans. It seems to me that would require the vm bit continuing to be set
while the page level bit get unset.
I *think* thats actually ok because whenever we set/clear the
visibilitymap we will still log it properly, so the crash safety
guarantees seem to hold true. Obviously we would have to change the
escape hatch for exactly that condition in vacuumlazy, but thats not a
problem...

I don't immediately see a problem with HS, your logic seems to hold
equally true there. The replay logic would need to be refined slightly,
but it looks possible. That is without having checked the code...

Greetings,

Andres Freund

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