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

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSoC proposal - "make an unlogged table logged"
Date: 2014-04-03 10:58:21
Message-ID: 533D3ECD.9010009@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/03/2014 01:44 PM, Andres Freund wrote:
> On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
>> On 04/01/2014 08:58 PM, Andres Freund wrote:
>>> On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
>>>> On 3/4/14, 8:50 AM, Andres Freund 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.
>>>>
>>>> Maybe I'm missing something, but doesn't this actually involve writing the data twice? Once into WAL and again into the relation itself?
>>>
>>> Yes. But as I said, that's unavoidable for anything but
>>> wal_level=minimal.
>>
>> Ideally, you would *only* write the data to WAL, when you do ALTER TABLE ...
>> SET LOGGED. There's no fundamental reason you need to rewrite the heap, too.
>> I understand that it might be difficult to do, because of the way the system
>> catalogs work, but it's worthy goal.
>
> I don't think that's realistic to achieve due to the issues described in
> http://archives.postgresql.org/message-id/CA%2BTgmob44LNwwU73N1aJsGQyzQ61SdhKJRC_89wCm0%2BaLg%3Dx2Q%40mail.gmail.com

To which I replied here:
http://www.postgresql.org/message-id/533AF9D7.7010503@vmware.com. Please
reply to that sub-thread with any problems you see. I might be missing
something, but I really don't see any insurmountable problem here.

> I don't think it's worthwile to make the feature much more complex, just
> to address this. perfect is the enemy of good and all that.

We should do the trivial implementation first, sure. But that ought to
be trivial. Now is the time to discuss how to do the more optimal thing.
If we can come up with a feasible design on that, Fabrizio will have
time to do that as part of the GSoC.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-03 11:04:54 Re: GSoC proposal - "make an unlogged table logged"
Previous Message Andres Freund 2014-04-03 10:47:00 quiet inline configure check misses a step for clang