<p></p>
<h2 dir="auto">What version of osm2pgsql are you using?</h2>
<p dir="auto">osm2pgsql version 1.6.0 (1.3.0-580-g061d4013)</p>
<h2 dir="auto">What operating system and PostgreSQL/PostGIS version are you using?</h2>
<p dir="auto">Ubuntu 20.04.1 LTS, PostgreSQL 14.2, PostGIS 3.2.0.</p>
<h2 dir="auto">Tell us something about your system</h2>
<p dir="auto">Bare metal Windows Hyper-V VM with 190GB RAM assigned to VM, 2x Xeon E5-2680 v4, 14C/28T each, 4x2TB NVMe PCIe 3.0 Windows Storage Space on HP Z840 workstation.</p>
<h2 dir="auto">What did you do exactly?</h2>
<p dir="auto">Imported Planet using a slightly modified version of the in-development flex version of 'openstreetmap-carto' Lua style file as available here:<br>
<a href="https://github.com/gravitystorm/openstreetmap-carto/blob/e7af9bd90799103955f1d3996201ce0904be1665/openstreetmap-carto.lua">https://github.com/gravitystorm/openstreetmap-carto/blob/e7af9bd90799103955f1d3996201ce0904be1665/openstreetmap-carto.lua</a></p>
<h2 dir="auto">What did you expect to happen?</h2>
<p dir="auto">The style mentioned above has special handling for administrative boundaries, and creates a custom 'planet-osm-admin' line geometry table with de-duplicated lines representing administrative boundaries of the highest level using stage 2 flex processing.</p>
<p dir="auto">The amount of data to be processed here is significant, as being administrative boundaries, but the total number of records to re-process limited, osm2pgsql reports:</p>
<p dir="auto">"There are 2335433 ways to reprocess"</p>
<p dir="auto">I would expect this to execute relatively fast considering the limited number of records of just over 2M.</p>
<h2 dir="auto">What did happen instead?</h2>
<p dir="auto">The re-processing "appears" slow. Note that this is a completely arbitrary statement, as I don't know exactly what is going on in this stage (expect for what it needs to create as output). I just notice it takes many hours of processing for a fairly limited amount of records (albeit being administrative boundaries, which can be huge).</p>
<h2 dir="auto">What did you do to try analyzing the problem?</h2>
<p dir="auto">One thing I noticed, and this is actually why I opened this issue, is that at this stage the only thing I see happening on the database - at least from the limited perspective of what the pgAdmin interface shows - is that pgAdmin shows a cycle of DELETE statements, where the WHERE clause appears to show batches of records being deleted:</p>
<p dir="auto"><a target="_blank" rel="noopener noreferrer" href="https://user-images.githubusercontent.com/7635726/153707048-f7d5e9d0-6c40-422e-a5c0-e1d356d98820.png"><img src="https://user-images.githubusercontent.com/7635726/153707048-f7d5e9d0-6c40-422e-a5c0-e1d356d98820.png" alt="afbeelding" style="max-width: 100%;"></a></p>
<p dir="auto">This makes me wonder if the actual issue is not so much the processing for stage 2 flex processing, or that the slowness might be caused by this DELETE operation going in batches over the records to delete using large WHERE clauses with lots of IN record references.</p>
<p dir="auto">Wouldn't it possibly be much more efficient and faster to create a secondary table with the osm_id of the records to delete, and then use a</p>
<p dir="auto"><code>DELETE FROM films USING producers  WHERE producer_id = producers.id AND producers.name = 'foo';</code></p>
<p dir="auto">type DELETE record statement with <strong>USING</strong> as also shown and documented on the PostgreSQL Help pages:</p>
<p dir="auto"><a href="https://www.postgresql.org/docs/14/sql-delete.html" rel="nofollow">https://www.postgresql.org/docs/14/sql-delete.html</a></p>
<p dir="auto">I know from my own experience in another application I wrote, that this seems quite efficient at deleting large numbers of records from an existing table. The PostgreSQL Help also seems to recommend it, although in reference to a comparison with a sub-select there:</p>
<blockquote>
<p dir="auto">In some cases the join style is easier to write or faster to execute than the sub-select style.</p>
</blockquote>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/osm2pgsql/issues/1640">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AA6353SIGNA6TUYQFTVFSEDU2YZEVANCNFSM5OGSOIUA">unsubscribe</a>.<br />Triage notifications on the go with GitHub Mobile for <a href="https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675">iOS</a> or <a href="https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub">Android</a>.
<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AA6353XA3GSETJN7SDI7VPTU2YZEVA5CNFSM5OGSOIUKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4Q4U5CLA.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><openstreetmap/osm2pgsql/issues/1640</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/openstreetmap/osm2pgsql/issues/1640",
"url": "https://github.com/openstreetmap/osm2pgsql/issues/1640",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>