Re: GSoC proposal - "make an unlogged table logged"

On 6 March 2014 19:42, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
> <fabriziomello(at)gmail(dot)com> wrote:
> > On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> > <fabriziomello(at)gmail(dot)com> wrote:
> >> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
> >> wrote:
> >> >
> >> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> >> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund <
> andres(at)2ndquadrant(dot)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.

Sounds like a plan. Would there be any stretch-goals for this work, or is
there not really anything else that could be done?

--
Thom