On 2014-04-03 15:02:27 +0300, Heikki Linnakangas wrote:
> On 04/03/2014 02:41 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
intothe 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.
> >
> >As another point: What's the advantage of that? The amount of writes
> >will be the same, no? It doesn't seem to be all that interesting that
> >a second filenode exists temporarily?
>
> Surely it's cheaper to read the whole relation and copy it to just WAL, than
> to read the whole relation and write it both the WAL and another file.
I have to admit I was thinking of the WAL replay case ;). But we'll
actually have to write all dirty s_b, change the persistency tags and
such anyway because there's no LSN interlock with checkpoints. That
seems pretty ugly as well, and once again, avoidable by a rewrite.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services