Some research on middle performance

[joto]

I did some research on how fast the import into the middle tables is and how much we could possible improve performance. For that I compared actual osm2pgsql runs with running COPY "manually".

All the numbers are based on a single run, so take them with a grain of salt.

All experiments were done with the new middle (--middle-database-format=new) and without flat node files, i.e. all nodes were imported into the database.

First I did an import with --slim -O null, i.e. without output tables to get the current baseline. Internally this will create the tables with a primary key constraint on the id column and then import the data using COPY. I looked only at the timings for that part, not at building extra indexes which happens later. Indexing will have to be done anyway and it happens completely in the database, so it is unlikely that we can do much about that part. I then dumped out the data in COPY format and re-created the same database by creating the tables and running COPY with psql. The time for this is the shortest time we can likely get, the difference between this time and the import time is the time needed to read and convert the OSM data, i.e. the necessary or unnecessary overhead generated by osm2pgsql.

I then tried some variations:

• Create the tables without primary key (PK) constraint and add that constraint later (which will build the index)
• COPY with FREEZE option
• Both of the above

Here are the timings (in minutes):

	PK	nodes	ways	rels	sum
osm2pgsql import	yes	263	77	3	343 (5.7h)
COPY	yes	241	78	3	322 (5.4h)
COPY FREEZE	yes	196	65	2	263 (4.4h)
COPY	no	142	60	2	204 (3.4h)
COPY FREEZE	no	127	50	2	179 (3.0h)
add primary key		29	4	0	33 (0.6h)
COPY + add PK		171	64	2	237 (4.0h)
COPY FREEZE + add PK		156	54	2	212 (3.5h)

Some results from this research:

• Our approach can most likely be improved upon, but it is not horrible. Compared to the best other result we need 5.7 instead of 3.5 hours. But we have to decode the OSM data and convert it into the COPY format. While this mostly happens in different threads, some overhead is inevitable here.
• It looks like using COPY FREEZE can improve the performance. For this to work we have to create the table in the same transaction as we do the COPY. This is not easily possible with the current code, but it is a change we could do.
• From the numbers here it seems to be significantly faster to create the table without the primary key constraint and add that later. But in another test where I also generated output tables, this did not make a difference. The reason is probably that osm2pgsql was busy so often doing other things, that PostgreSQL had the time to update the indexes while the import ran. So it might be possible to get some improvement here in a real situation, but it is not quite as clear-cut as the numbers here suggest.

We also have to keep in mind that the situation is different if we use a flat nodes file. (And also different if we use the --extra-attributes option.)

And for real situations we have interaction between the middle and the output which I haven't looked at in detail so far. Most nodes don't have any tags, so they don't take up any time in the output code, the middle code is the bottleneck here. For the ways this situation is reversed, the middle is reasonably simple, the output runs some Lua code for basically every way, which is almost certainly the bottleneck.

[pnorman]

• From the numbers here it seems to be significantly faster to create the table without the primary key constraint and add that later. But in another test where I also generated output tables, this did not make a difference. The reason is probably that osm2pgsql was busy so often doing other things, that PostgreSQL had the time to update the indexes while the import ran. So it might be possible to get some improvement here in a real situation, but it is not quite as clear-cut as the numbers here suggest.

We should move to creating the UNIQUE index after loading the data. It might not have sped up your test, but I believe it would on some hardware with a different number of threads. Additionally, the resulting index is properly balanced without dead tuples in it.

• It looks like using COPY FREEZE can improve the performance. For this to work we have to create the table in the same transaction as we do the COPY. This is not easily possible with the current code, but it is a change we could do.

This would rule out ever having multiple threads writing to the middle at the same time. Do we want to do that?