On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes <jeff.janes@gmail.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.
Patch is simple enough. All usage looks safe, so I reckon this is good.
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?
Easy enough to do it at the end of the COPY FREEZE in one step. No need to wait until EOXact.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
