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_eidmappings | 7983639 | 957829 | 68 | 7025810 | 88% | 103932 |
| electricjunctionobject | 527421 | 157201 | 20 | 370220 | 70% | 18831 |
| un_6_associations | 473888 | 368256 | 14 | 105632 | 22% | 7819 |
| un_6_dirtyareas | 425856 | 110420 | 6 | 315436 | 74% | 49133 |
| electricdevice | 397987 | 211428 | 34 | 186559 | 47% | 5502 |
| un_6_subnetworks | 385461 | 138946 | 167 | 246515 | 64% | 1477 |
| electricsubnetline | 374137 | 138036 | 200 | 236101 | 63% | 1183 |
| electricline | 241855 | 132954 | 3 | 108901 | 45% | 40334 |
| un_6_junctions | 223761 | 45008 | 0 | 178753 | 80% | 940805 |
| structurejunction | 151429 | 127753 | 1 | 23676 | 16% | 20952 |
| un_6_aggregations | 148090 | 55346 | 0 | 92744 | 63% | 713415 |
| un_6_systemjunctions | 137440 | 17326 | 1 | 120114 | 87% | 176638 |
| electricjunction | 103885 | 76691 | 1 | 27194 | 26% | 28625 |
| un_6_edges | 98835 | 19959 | 0 | 78876 | 80% | 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
@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.
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.