On Tue, Oct 20, 2015 at 7:02 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes <jeff.ja...@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. 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
copy_freeze_all_visible_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
