Re: Freeze avoidance of very large table.

On Wed, Jul 8, 2015 at 10:10 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> On Thu, Jul 9, 2015 at 4:31 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)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