Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAA-aLv7iRnht70WsXGOJuEk5CS_Khc77SmoiZNpGJng6NF8wDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Freeze avoidance of very large table.
Список pgsql-hackers
On 17 November 2015 at 15:43, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 11/17/15 4:41 AM, Thom Brown wrote:
>>
>> Could someone post a TL;DR summary of what the current plan looks
>> like?  I can see there is a huge amount of discussion to trawl back
>> through.  I can see it's something to do with the visibility map.  And
>> does it avoid freezing very large tables like the title originally
>> sought?
>
>
> Basically, it follows the same pattern that all-visible bits do, except
> instead of indicating a page is all-visible, the bit shows that all tuples
> on the page are frozen. That allows a scan_all vacuum to skip those pages.

So the visibility map is being repurposed?  And if a row on a frozen
page is modified, what happens to the visibility of all other rows on
that page, as the bit will be set back to 0?  I think I'm missing a
critical part of this functionality.

Thom



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extracting fields from 'infinity'::TIMESTAMP[TZ]