Manual index configuration for id indexes?

[joto]

I noticed a problem with the new manual index creation options as per #1780: The id indexes are explicitly exempt from the configuration. Osm2pgsql will create an id index when it needs the index itself, i.e. when it creates a database for updates. Now if the user needs an index on the id column for some other reason everything is fine as long as we are creating a database for updates, the user can just use the index osm2pgsql creates for itself. But if the database is not created for updates, the user has to add that index to the configuration. But this means the configuration depends on whether the user creates an updatable database or not which is somewhat confusing and annoying for the user, especially because there is a good chance testing is done on a non-updatable database and then the final production import is updatable and the result are two (probably even identical) indexes on the id column.

[pnorman]

This is something I've run into a few times. I have ID indexes for dev work so I can fetch particular objects for testing, but have to manually create them.

[lonvia]

I see two possible solutions:

1. Have a special index method that creates a id index and allow that do be added to the index definition, something like: ... indexes={{column='node_id', method='id-index'}} ....
2. Add an option to the id definition: ... ids = { type = 'node', id_column = 'node_id', create_index = 'always'}, ....

The first has the advantage that all indexes are in the same place but it is less obvious what it means and has some potential to be used wrongly. So I'd go for the second option.

[joto]

@pnorman This issue is specific to id indexes. If you need other indexes only in some setups you have to write your Lua script accordingly and use, for instance, an environment variable to switch between different setups.

[pnorman]

I am talking about ID indexes.

[rustprooflabs]

I see two possible solutions:

1. Have a special index method that creates a id index and allow that do be added to the index definition, something like: ... indexes={{column='node_id', method='id-index'}} ....
2. Add an option to the id definition: ... ids = { type = 'node', id_column = 'node_id', create_index = 'always'}, ....

The first has the advantage that all indexes are in the same place but it is less obvious what it means and has some potential to be used wrongly. So I'd go for the second option.

I prefer option two as well.

[joto]

The problem with (2) is that you can't use the more simple define_node/way/relation/area_table() functions any more but have to use define_table(). Maybe with all the extra things we have been doing on the table definitions the simplified functions aren't that great any more anyway and we want to deprecate them?

For option (2), that are the values for create_index?

• Do we want to use native data types: true for always create, nil (default) for "create for updateable databases", maybe false for "never create" (which might be useful if you want to create them manually in some specific way?) or
• use strings: "always", "never", "auto" (default)?

[lonvia]

I'd go with strings always and auto for now. never might just be asking for trouble.

[joto]

This was implemented in #1894.