[Tile-serving] [openstreetmap/osm2pgsql] Possible (micro) optimization to the COPY stage of import? (Discussion #1991)
mboeringa
notifications at github.com
Thu Jul 6 20:26:01 UTC 2023
I have no idea if this is actually a (micro) optimization worth pursuing, but I noticed in the [PostgreSQL help topic related to COPY](https://www.postgresql.org/docs/current/populate.html#POPULATE-COPY-FROM) 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](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-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.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/discussions/1991
You are receiving this because you are subscribed to this thread.
Message ID: <openstreetmap/osm2pgsql/repo-discussions/1991 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20230706/fc14cc3d/attachment.htm>
More information about the Tile-serving
mailing list