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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
