Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAMkU=1yL8pq4kJ3sU4GqbPLkr7B_=XWyLDtorE91Hi6MauerFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Wed, Jul 8, 2015 at 10:10 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
On Thu, Jul 9, 2015 at 4:31 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko <sawada.mshk@gmail.com>
> wrote:
>>
>> It's impossible to have VM bits set to frozen but not visible.
>> These bit are controlled independently. But eventually, when
>> all-frozen bit is set, all-visible is also set.
>
>
> If that combination is currently impossible, could it be used indicate that
> the page is all empty?

Yeah, the status of that VM bits set to frozen but not visible is
impossible, so we could use this status for another something status
of the page.

> Having a crash-proof bitmap of all-empty pages would make vacuum truncation
> scans much more efficient.

The empty page is always marked all-visible by vacuum today, it's not enough?

The "current" vacuum can just remember that they were empty as well as all-visible.

But the next vacuum that occurs on the table won't know that they are empty, just that they are all-visible, so it can't truncate them away without having to read each one first.

It is a minor thing, but if there is no other use for this fourth "bit-space", it seems a shame to waste it when there is some use for it.  I haven't looked at the code around this area to know how hard it would be to implement the setting and clearing of the bit.

Cheers,

Jeff

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: 9.5 release notes
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Resource Owner reassign Locks