Re: GSoC proposal - "make an unlogged table logged" - Mailing list pgsql-hackers

From Fabrízio de Royes Mello
Subject Re: GSoC proposal - "make an unlogged table logged"
Date
Msg-id CAFcNs+o-+UiBwYfMp7Ac2viu3mCUGy+5qqP+Y8_ik4iCffcoWw@mail.gmail.com
Whole thread
In response to Re: GSoC proposal - "make an unlogged table logged"  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: GSoC proposal - "make an unlogged table logged"
List pgsql-hackers

On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund <andres@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 <andres@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?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Fwd: patch: make_timestamp function
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To: