On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello <fabriziome...@gmail.com> wrote: > On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello > <fabriziome...@gmail.com> wrote: >> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund <and...@2ndquadrant.com> >> wrote: >> > >> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote: >> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund <and...@2ndquadrant.com> >> > > wrote: >> > > > On 2014-03-04 09:47:08 -0500, Robert Haas wrote: >> > > > Can't that be solved by just creating the permanent relation in a >> > > > new >> > > > relfilenode? That's equivalent to a rewrite, yes, but we need to do >> > > > that >> > > > for anything but wal_level=minimal anyway. >> > > >> > > Yes, that would work. I've tended to view optimizing away the >> > > relfilenode copy as an indispensable part of this work, but that might >> > > be wrongheaded. It would certainly be a lot easier to make this >> > > happen if we didn't insist on that. >> > >> > I think it'd already much better than today's situation, and it's a >> > required codepath for wal_level > logical anyway. So even if somebody >> > wants to make this work without the full copy for minimal, it'd still be >> > a required codepath. So I am perfectly ok with a patch just adding that. >> > >> >> Then is this a good idea for a GSoC project ? >> >> I don't know very well this internals, but I am willing to learn and I >> think the GSoC is a good opportunity. >> >> Any of you are willing to mentoring this project? >> > > I written the proposal to this feature, so I would like to know if someone > can review.
I think this isn't a good design. Per the discussion between Andres and I, I think that I think you should do is make ALTER TABLE .. SET LOGGED work just like VACUUM FULL, with the exception that it will set a different relpersistence for the new relfilenode. If you do it that way, this will be less efficient, but much simpler, and you might actually finish it in one summer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers