Repository navigation
Replace geometry check trigger by WHERE condition on COPY - #2500
Merged
Merged
Conversation
Since version 12 PostgreSQL supports a WHERE condition on the
COPY command. Use this to add a geometry check when adding data
to the database instead of the trigger we used before.
This makes the code simpler and doesn't clutter the database with
triggers.
If you have already imported a database with an older version of
osm2pgsql and want to use this new version, that will still work. But
the original triggers will still be there so there is some extra work
done for each update. Simply remove the triggers and trigger functions
from the database with commands of the form
DROP TRIGGER *_osm2pgsql_valid ON *;
DROP FUNCTION *_osm2pgsql_valid;
PostgreSQL 12 is currently the oldest database version we support.
This also makes the version of the proj library osm2pgsql was compiled
with available in the Lua config as the "osm2pgsql.proj_version" string
variable. It is set to '[disabled]' if osm2pgsql was compiled without
proj support. It is needed for this so we can disable the test if proj
is not available.
joto
added a commit
that referenced
this pull request
Oct 25, 2026
Fixes #2286 This PR switches the Postgres COPY for the middle tables and most flex tables from the textual format to the binary format. This is a moderate win in decreasing CPU time that is otherwise spent on int-to-text-to-int, float-to-text-to-float, WKB hex, etc. Details: - Each `db_target_descr_t` knows the binary versions of its column types, if present `db_copy_mgr_t` will seamlessly switch to binary format for the same calls (`add_column`, `new_array`, etc) - Binary mode checks each field's type from the list, asserting that it matches - Middle tables will always use binary mode. In particular, `int8[]` is supported, to make this possible. - Flex tables use binary mode if they only use the following types: text, boolean, int2/4/8, real, double precision, hstore, json, jsonb, direction, id columns, and all geometry types. It will fall back to text mode if user-defined SQL types are present, or if there is timestamp/timestamptz directly from Lua as an arbitrary string. While I could have supported that last possibility, there is a better alternative (#2502) that doesn't require complicated timestamp parsing code. - Pgsql output and gen are unchanged, still text. - #2500 is supported Changes to behavior: - No change for integers, doubles, text, json, hstore, arrays, timestamps, or WKB from OSM data. - If the Lua gives a double which is stored in PG as a `real`, currently text mode implicitly does fp64 -> text -> fp32. This causes rounding to happen twice. Binary mode will now round fp64 -> fp32 directly. Of course, one could reimplement the double rounding behavior, but I don't think this is good behavior to preserve. The effect is at most 1 ULP of difference, and it only happens when a fp64 landed exactly halfway between two fp32 values, which is extremely unlikely. A potential place where this could theoretically arise is in `way_area` - but in practice, there are none, in the full current planet, that have any difference here, and there probably never will be, as less than 1 in a billion doubles are like this. Out of range values like inf remain an error as in text mode. Testing: - Lots of tests in `test-db-copy-mgr.cpp` - All ctest and BDD pass - Tested all examples in flex-config, and also osm carto. Imported with `--slim -x` and then updated with an .osc. (this is what exposed #2501). All table contents identical to master. Performance: - Ryzen 9 3900X, Samsung 970 EVO Plus NVMe, Postgres 18.6, PostGIS 3.6.4 - OSM Carto flex style. Nodes cached in RAM (no flat nodes.bin). - Cold restart every time - Alternating runs between this branch and master, taking the median of seven. |Extract (from geofabrik)|Flags|Wall clock time|Postgres CPU, import phase|Postgres CPU, total|osm2pgsql CPU| |---|---|---|---|---|---| | Delaware | `--slim` | 12.74 -> 12.36 s (−3.0%) | 7.45 -> 6.44 s (−13.6%) | 13.03 -> 12.03 s (−7.7%) | 6.92 -> 6.59 s (−4.8%) | | Delaware | `--slim --drop` | 12.36 -> 12.02 s (−2.8%) | 6.64 -> 5.69 s (−14.3%) | 9.00 -> 8.05 s (−10.6%) | 6.89 -> 6.57 s (−4.6%) | | New Jersey | `--slim` | 83.81 -> 80.37 s (−4.1%) | 47.66 -> 41.17 s (−13.6%) | 86.74 -> 80.13 s (−7.6%) | 48.11 -> 45.73 s (−4.9%) | So as we can see Postgres spends about 14% less CPU to ingest. The overall win to wall clock time is currently not so much because we are bottlenecked by the single threaded Lua processing time. The benefit from this PR is larger when combined with upcoming PRs... (teaser post credit scene 😺) (EDIT: this was teasing #2504)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since version 12 PostgreSQL supports a WHERE condition on the COPY command. Use this to add a geometry check when adding data to the database instead of the trigger we used before.
This makes the code simpler and doesn't clutter the database with triggers.
If you have already imported a database with an older version of osm2pgsql and want to use this new version, that will still work. But the original triggers will still be there so there is some extra work done for each update. Simply remove the triggers and trigger functions from the database with commands of the form
DROP TRIGGER *_osm2pgsql_valid ON *;
DROP FUNCTION *_osm2pgsql_valid;
PostgreSQL 12 is currently the oldest database version we support.