On Fri, Jul 10, 2015 at 3:42 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Wed, Jul 8, 2015 at 10:10 PM, Sawada Masahiko <sawada.m...@gmail.com> > wrote: >> >> On Thu, Jul 9, 2015 at 4:31 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> > On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko <sawada.m...@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.
Yeah, it would be effective for vacuum empty page. > > 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. I think so too, we would be able to use unused fourth status of bits efficiently. Should I include these improvement into this patch? This topic should be discussed on another thread after this feature is committed, I think. Regards, -- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
