Select to view content in your preferred language

Feedback on the Prune Branch History Tool

945
21
06-23-2026 05:03 PM
PierreloupDucroix
MVP Regular Contributor

Hello,

I'd like to share my experience with the prune branch history tool.

After a year of using Utility Network in production, we've accumulated a lot of versions and branch versioning history.

I've therefore started a process to delete versions (which will be automated in the future) and prune the history.

I have several observations and questions.

First, here are some raw statistics.
Total processing time: 8 hours and 34 minutes.

table_name

 records_count 

before_prune 

 records_count 

after_prune 

 duration_logs 

postgre (min) 

delete 

count

delete 

stats

 row_per 

min_ratio 

un_6_eidmappings7983639957829                      68702581088%103932
electricjunctionobject527421157201                      2037022070%18831
un_6_associations473888368256                      1410563222%7819
un_6_dirtyareas425856110420                        631543674%49133
electricdevice397987211428                      3418655947%5502
un_6_subnetworks385461138946                    16724651564%1477
electricsubnetline374137138036                    20023610163%1183
electricline241855132954                        310890145%40334
un_6_junctions22376145008                        017875380%940805
structurejunction151429127753                        12367616%20952
un_6_aggregations14809055346                        09274463%713415
un_6_systemjunctions13744017326                        112011487%176638
electricjunction10388576691                        12719426%28625
un_6_edges9883519959                        07887680%985950

1- We can see that the main table to prune is the eidmappings table, which isn't unusual, given that I've had to disable/enable the topology several times to improve the data model, which is known to increase the size of this table.

2- We can see that the time spent on certain tables compared to the number of rows deleted is very long, mainly subnetworks and subnetline. These two tables alone account for 70% of the processing time, with a very low ratio of rows processed. Is this normal?

3- It's not visible in the statistics, but the size of the database tables doesn't seem to have decreased. For example, the eidmapping table is still around 2GB after processing, just like before. Are there any additional processes that should be run on the database to reduce the allocated space (Vacuum, for example)?

4- Surprisingly, I first pruned one month of branch history (January 2025, no previous history), then one year (all of 2025), and the time spent was roughly the same (about 8 hours total, with 70% of that time spent on the two tables, subnet and subnetline).

Context : Pro 3.5.7, AGE and SDE 11.5, UN v6

CEO of MAGIS
21 Replies
RobertKrisher
Esri Regular Contributor

@Thomas_Brown Sam has already included the logs in his post that show how long validate consistency is taking, how many features are returned by the trace, and the other items you asked about.

0 Kudos
RobertKrisher
Esri Regular Contributor

for instructions on how to enable logging to start capturing detailed performance information, check this article: Utility Network Diagnostics . Verbose will get you the trace logs, debug will get you access to even more information about all the queries. Remember that switching to a more detailed logging method like this will impact performance, so its best to do it in a QaQc environment. If you do make the change in production, make sure its only for a short amount of time.