Re: Set visibility map bit after HOT prune

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Set visibility map bit after HOT prune
Дата
Msg-id 20121216164053.GG4683@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Set visibility map bit after HOT prune  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 2012-12-16 16:25:03 +0000, Simon Riggs wrote:
> On 16 December 2012 14:41, Andres Freund <andres@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Serious problem: media recovery fails after system or PostgreSQL crash
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: logical decoding - GetOldestXmin