Re: COPY FREEZE and PD_ALL_VISIBLE

On Tue, Oct 20, 2015 at 7:02 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > I'm planning on adding a todo item to have COPY FREEZE set
> PD_ALL_VISIBLE.
> > Or is there some reason this can't be done?
> >
> > Since the whole point of COPY FREEZE is to avoid needing to rewrite the
> > entire table, it seems rather perverse that the first time the table is
> > vacuumed, it needs to rewrite the entire table.
>
> *facepalm*
>
> I don't know how hard that is to implement, but +1 for trying to
> figure out a way.
>

It turns out it was pretty easy to set PD_ALL_VISIBLE on the new pages,
since the code in hio that requests the relation to be extended already has
info on the tuple's intended freeze status.

Then you just need to refrain from clearing PD_ALL_VISIBLE when that tuple
is actually written into the page. Not only because clearing would defeat
the purpose, but also because it will cause an error--apparently the
incipient page is not yet in a state where visibilitymap_clear is willing
to deal with it.

With this patch, you get a table which has PD_ALL_VISIBLE set for all
pages, but which doesn't have a _vm file. Index-only scans will visit the
heap for each tuple until the first VACUUM is done.

The first vacuum will read the entire table, but not need to write it
anymore. And will create the _vm file.

I think we really want to create _vm file as well as set PD_ALL_VISIBLE,
but I don't know the best way to do that. Set a flag somewhere and then
create it in bulk at the end of the transaction? Set it bit by bit as the
pages are extended and initialized?

Cheers,

Jeff