> 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/[email protected]>
_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
