Thanks for your detailed report. We have seen similiar problems before, but
with much larger change files. It seems this can happen also with smaller
change files. The problem is indeed the `INSERT INTO osm2pgsql_changed_ways
...` query. For some reason PostgreSQL chooses a really bad plan for this
rather simple query and the query then takes forever. Maybe this is related to
the PostgreSQL version or something else we have not understood yet, because
this works perfectly well in other cases. (Which also means that generally
minutely updates do work fine, the change files are small and updates are fast.)
Apart from the PostgreSQL version, I can see two things that are "special" in
your setup that could affect this: The setting for `default_statistics_target`
is much higher than the default, generally this should *improve* the planner
results, but who knows. The other thing is that you are only using DACH data
and not the planet. In DACH the data is much "denser" than the average for the
planet, so maybe this has something to do with it.
The idle `COPY` command should hopefully not affect this. But you could try
osm2pgsql 2.0.0 where this issue is fixed and the COPY command is closed much
earlier.
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/issues/2266#issuecomment-2431132453
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/issues/2266/[email protected]>
_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
