Re: Disable WAL logging to speed up data loading

Greetings,

* Laurenz Albe (laurenz(dot)albe(at)cybertec(dot)at) wrote:
> On Mon, 2021-03-22 at 09:46 -0400, Stephen Frost wrote:
> > * tsunakawa(dot)takay(at)fujitsu(dot)com (tsunakawa(dot)takay(at)fujitsu(dot)com) wrote:
> > > From: Stephen Frost <sfrost(at)snowman(dot)net>
> > > > The argument here seems to stem from the idea that issueing a 'TRUNCATE'
> > > > inside the transaction before starting the 'COPY' command is 'too hard'.
> > >
> > > No, we can't ask using TRUNCATE because the user wants to add data to a table.
> >
> > First- what are you expecting would actually happen during crash
> > recovery in this specific case with your proposed new WAL level?
> >
> > Second, use partitioning, or unlogged tables (with the patch discussed
> > elsewhere to allow flipping them to logged without writing the entire
> > thing to WAL).
>
> Perhaps allowing to set unlogged tables to logged ones without writing WAL
> is a more elegant way to do that, but I cannot see how that would be any
> more crash safe than this patch. Besides, the feature doesn't exist yet.

I'm not suggesting it's somehow more crash safe- but it's at least very
clear what happens in such a case, to wit: the entire table is cleared
on crash recovery.

> So I think that argument doesn't carry much weight.

We're talking about two different ways to accomplish essentially the
same thing- one which introduces a new WAL level, vs. one which adds an
optimization for a WAL level we already have. That the second is more
elegant is more-or-less entirely the point I'm making here, so it seems
pretty relevant.

Thanks,

Stephen