<p></p>
<p dir="auto">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".</p>
<p dir="auto">All the numbers are based on a single run, so take them with a grain of salt.</p>
<p dir="auto">All experiments were done with the new middle (<code class="notranslate">--middle-database-format=new</code>) and without flat node files, i.e. all nodes were imported into the database.</p>
<p dir="auto">First I did an import with <code class="notranslate">--slim -O null</code>, 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.</p>
<p dir="auto">I then tried some variations:</p>
<ul dir="auto">
<li>Create the tables without primary key (PK) constraint and add that constraint later (which will build the index)</li>
<li>COPY with FREEZE option</li>
<li>Both of the above</li>
</ul>
<p dir="auto">Here are the timings (in minutes):</p>
<table role="table">
<thead>
<tr>
<th></th>
<th>PK</th>
<th align="right">nodes</th>
<th align="right">ways</th>
<th align="right">rels</th>
<th align="right">sum</th>
</tr>
</thead>
<tbody>
<tr>
<td>osm2pgsql import</td>
<td>yes</td>
<td align="right">263</td>
<td align="right">77</td>
<td align="right">3</td>
<td align="right">343 (5.7h)</td>
</tr>
<tr>
<td>COPY</td>
<td>yes</td>
<td align="right">241</td>
<td align="right">78</td>
<td align="right">3</td>
<td align="right">322 (5.4h)</td>
</tr>
<tr>
<td>COPY FREEZE</td>
<td>yes</td>
<td align="right">196</td>
<td align="right">65</td>
<td align="right">2</td>
<td align="right">263 (4.4h)</td>
</tr>
<tr>
<td>COPY</td>
<td>no</td>
<td align="right">142</td>
<td align="right">60</td>
<td align="right">2</td>
<td align="right">204 (3.4h)</td>
</tr>
<tr>
<td>COPY FREEZE</td>
<td>no</td>
<td align="right">127</td>
<td align="right">50</td>
<td align="right">2</td>
<td align="right">179 (3.0h)</td>
</tr>
<tr>
<td>add primary key</td>
<td></td>
<td align="right">29</td>
<td align="right">4</td>
<td align="right">0</td>
<td align="right">33 (0.6h)</td>
</tr>
<tr>
<td>COPY + add PK</td>
<td></td>
<td align="right">171</td>
<td align="right">64</td>
<td align="right">2</td>
<td align="right">237 (4.0h)</td>
</tr>
<tr>
<td>COPY FREEZE + add PK</td>
<td></td>
<td align="right">156</td>
<td align="right">54</td>
<td align="right">2</td>
<td align="right">212 (3.5h)</td>
</tr>
</tbody>
</table>
<p dir="auto">Some results from this research:</p>
<ul dir="auto">
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<p dir="auto">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.)</p>
<p dir="auto">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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/osm2pgsql-dev/osm2pgsql/issues/2110">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AA6353TGROKTDVF6CAC76ILYHXQ5TAVCNFSM6AAAAABAGEA4R2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDIMBXGMYTOMQ">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AA6353QDOXMBP5YY4HG7JFTYHXQ5TA5CNFSM6AAAAABAGEA4R2WGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHRJHH2Q.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><osm2pgsql-dev/osm2pgsql/issues/2110</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/osm2pgsql-dev/osm2pgsql/issues/2110",
"url": "https://github.com/osm2pgsql-dev/osm2pgsql/issues/2110",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>