Performance: Create indices after or before converting from UNLOGGED to LOGGED?

Question

I'm working on a software that initially populates tables with a lot of data (bulk mode), after which it switches to "normal" mode of operation.

To make bulk mode fast, I'm starting with UNLOGGED tables with almost no indices (among other things).

After loading all the initial data I switch to to normal mode: I'm creating indices and altering the tables to be LOGGED again.

My question is: performance wise - is there any difference in order of creating indices and changing to LOGGED tables? From reliability perspective, it seems that the fastest I switch to LOGGED, the better (lower chance of loosing all my precious data). But will I have to pay for it in time it takes to create all the indices?

In my initial tests, it seems that ALTER TABLE x SET LOGGED is taking quite a bit of time, which I don't understand because I thought it affects only operations after it, and in itself is almost an NO-OP.

My PG is:

PostgreSQL 9.6.11 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit

though I'm asking more generally. Any links to things that would help my understand what exactly is going on with UNLOGGED and LOGGED (especially in combination with indicies) would be also appreciated.

Answer 1

You will not gain as much as you think if you load data into an unlogged table and then change it to a logged one, no matter at which point you create the indexes.

The benefit of unlogged tables is that no WAL (transaction log) is written. But when you turn an unlogged table into a logged one, WAL for the complete table and its indexes will be written. This is necessary, because now PostgreSQL has to be able to recover the table in case of a crash.

Your gain is that the WAL will be written block-wise instead of row by row.

Unlogged tables become a big advantage if you have to modify the data between the time when you load the table and when you turn it into a logged one. All these modifications won't have to be WAL logged.