-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed up osmosis_highway_deadend sql20 #2097
Conversation
The inner As it use a |
I'm not sure if I understand what you mean, but this would probably cause the
I'll give it a try in a couple of days. |
Checking for bicycle parking ways is a very slow part of the sql, but this is only relevant for cycleways. Skip it for car roads. Use indices for ferry and bicycle parkings
13bd81a
to
b2452a9
Compare
Ok, couple of hours actually :) With ferry and bicycle_parking in their own No clue why the second (and all subsequent) run is so much faster this time, possibly osm110 was busy the first time. But all of the first runs seem an improvement already. japan_chubu
|
Thank you. |
The slowest part of this analyser is
sql20
, specifically the twoLEFT JOIN
s. (Combining them into a singleLEFT JOIN
didn't improve much).sql20
comprises about 30-50% of the runtime of the osmosis_highway_deadend analyser for some extracts that I tested.Current situation
(sql20 only, 2 runs)
EXPLAIN ANALYZE
-> see below)Proposed solution and new situation
Checking for bicycle parkings as valid end points for car roads doesn't make much sense. Hence, only executing that check for cycleways results in the following
(sql20+21+22, 2 runs)
EXPLAIN ANALYZE
-> see below)Some extracts are not really affected, others improve by nearly a factor 2 (for this part of the analyser only). I suspect it depends on how many bicycle parkings and/or cycleways and/or tertiary-and-above-roads there are in the country (and how much they're split up into small or long way fragments).