Possible (micro) optimization to the COPY stage of import?

[mboeringa]

I have no idea if this is actually a (micro) optimization worth pursuing, but I noticed in the PostgreSQL help topic related to COPY the following statement related to WAL and COPY:

COPY is fastest when used within the same transaction as an earlier CREATE TABLE or TRUNCATE command. In such cases no WAL needs to be written, because in case of an error, the files containing the newly loaded data will be removed anyway. However, this consideration only applies when wal_level is minimal as all commands must write WAL otherwise.

Of course, this is not a general improvement given the constraints, but I still wonder if there might be value for osm2pgsql putting the COPY statement in the same transaction as the CREATE TABLE as suggested here for the loading of nodes, ways an relations in case of initial imports?

Anyway, I have no idea how much WAL influences performance these days with NVMe SSDs abounding, it might be an old remark in the PostgreSQL Help dating from the time of HDD RAIDs only.

[pnorman]

Of course, this is not a general improvement given the constraints, but I still wonder if there might be value for osm2pgsql putting the COPY statement in the same transaction as the CREATE TABLE as suggested here for the loading of nodes, ways an relations in case of initial imports?

This is not a consideration because on import the data is loaded into UNLOGGED tables, which do not use the WAL.