Some of the `update_osm_${LAYER}`-functions, which are executed by triggers on updates, execute an UPDATE statement on the same tables that have these triggers. This causes the trigger functions `flag` and `store` to run multiple times for one record.
For instance, if I add log in the trigger functions and run an INSERT on `osm_housenumber_point`, this output is generated:
```
NOTICE: Store
NOTICE: Flag
NOTICE: Refresh housenumber
NOTICE: Flag
NOTICE: Store
NOTICE: Flag
INSERT 0 1
```
If we limit the triggers from executing if they are called from another trigger using `pg_trigger_depth() < 1`, the triggers will only be triggered once per record:
```
NOTICE: Store
NOTICE: Flag
NOTICE: Refresh housenumber
INSERT 0 1
```
This will prevent redunant executions and might improve update performance.
Co-authored-by: Patrik Sylve <patrik.sylve@t-kartor.com>
Improved update performance of poi layer
- Refactored update_poi_point.sql to partial diff update
- Refactored IDs to be unique in poi_polygon.osm_ids
- Restricted updates to INSERT and UPDATE operations during poi_polygon.refresh
- Added analyze statements before update queries during poi_polygon.refresh
Replacing update on the whole table with an update only on changed rows.
The goal is to update more quickly by just updating the changing content.
The update now focus on osm_id of changed rows, it use index. Add a where clause tags != update_tags(tags, geometry) en ensure only update when changed.
It requires one more trigger and a table to store changed osm_id.
The UPDATE is keep in a function to be reusable for initial setup and trigger update.
I try many code layout before done it in this way with the goal to keep the code for initial pass and for update. It should have low impact on initial data load. Better performance for row update can be achieve with BEFORE UPDATE, but require to duplicate the logic.
It is not based on the already merged https://github.com/openmaptiles/openmaptiles/pull/896 because calling and update within a function for each updated row was not efficient for larger table (like housenumber).
It addresses #814.
* Remake update_peak_point use incremental update #814
* Make update_aerodrome_label_point use incremental update #814
* Make housenumber_centroid use incremental update #814
* Make update_continent_point use incremental update #814
* Make update_island_point use incremental update #814
* Make update_island_polygon use incremental update #814
* Remove dead code in update_state_point.sql
* Make update_state_point use incremental update #814
* Remove dead code in update_country_point.sql
* Make update_country_point use incremental update #814
* Make osm_poi_polygon use incremental update #814
Thanks @frodrigo
I would like to reformat all of our SQL to have a concise coding style.
This makes it far easier to understand the code for a casual contributor,
and lets us spot errors more easily.
Most importantly, it makes it much easier to grep (search) the code because it is more likely to be in the same syntax
Some key changes:
* SQL keywords are always UPPERCASE, e.g. `SELECT WHEN AS END ...`
* types, variables, aliases, and field names (identifiers) are always lower case
* `LANGUAGE 'plpgsql'` is now `LANGUAGE plpgsql` (no quotes)
* a few minor spacing/semicolon cleanups
P.S. Per @TomPohys request, `TABLE` is spelled using upper case despite being a type for consistency with PG Docs. Same for `LANGUAGE SQL` vs `LANGUAGE plpgsql`.
