Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAMkU=1xSO9v6yJH=dZopKWU7BexeJ=P_x9W-F4qwjt80U-vi+w@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 2 July 2015 at 16:30, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>
>>
>> Also, the flags of each heap page header might be set PD_ALL_FROZEN,
>> as well as all-visible
>
>
> Is it possible to have VM bits set to frozen but not visible?
>
> The description makes those two states sound independent of each other.
>
> Are they? Or not? Do we test for an impossible state?
>

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?

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

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Fillfactor for GIN indexes
Next
From: Paul Ramsey
Date:
Subject: Re: Hashable custom types