[Tile-serving] [osm2pgsql-dev/osm2pgsql] Some research on middle performance (Issue #2110)

[Paul Norman]

> Unfortunately using COPY FREEZE does not work together with parallel COPYs, because you need to create the table in the same transaction that you do the COPY FREEZE in. I tried using [snapshot synchronization](https://www.postgresql.org/docs/17/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION) to overcome this, but it didn't work. Maybe I didn't do it right, but there is probably something in there that prevents this from working, my transactions always got rolled back when I tried doing this.

I don't think parallel COPY FREEZE is possible with snapshot syncronization. The docs state

> But note that any database changes made by any one of these transactions remain invisible to the other transactions, as is usual for changes made by uncommitted transactions. So the transactions are synchronized with respect to pre-existing data, but act normally for changes they make themselves

The starting place is syncronized, but they're still separate transactions which can diverge.

Do we need to worry about the gains from freezing tuples at COPY time? We have to run `VACUUM ANALYZE;` on the table to update the Free Space Map and get statistics for query planning. We *should* be running `VACUUM FREEZE ANALYZE` after tables are done, not just `VACUUM ANALYZE`. I'm wondering if that changes any of the numbers

-- 
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/issues/2110#issuecomment-2568351107
You are receiving this because you are subscribed to this thread.

Message ID: <osm2pgsql-dev/osm2pgsql/issues/2110/2568351107 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20250102/4eea0f03/attachment-0001.htm>