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 по дате отправления: