topic Re: Feedback on the Prune Branch History Tool in ArcGIS Utility Network Questions

Feedback on the Prune Branch History Tool

PierreloupDucroix — Wed, 24 Jun 2026 00:07:09 GMT

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

Re: Feedback on the Prune Branch History Tool

RobertKrisher — Wed, 24 Jun 2026 12:49:45 GMT

Depending on the database you're using you may need to run something like a prune or vacuum if you want to reclaim the disk space associated with deleted records. If you are pruning on a regular basis, then doing this after every prune isn't necessary, since you'll need to reallocate the same disk space. If you've hit some kind of unreasonable high water mark, then reclaiming the disk space may be worth while.

Re: Feedback on the Prune Branch History Tool

TomBrown — Wed, 24 Jun 2026 13:24:56 GMT

Pierreloup thank you for your post and this level of detail you've captured.

My first question, I'm surprised you feel as if you need to prune at this point - there really isn't much historical data (row counts for these tables are very small). Are you pruning with the objective to reclaim storage or the need to address performance issues. If its performance related (hopefully not), it would be valuable to identify what is causing the performance issue - any specific queries?

Why is the prune spending so much time on those two specific tables... we would need to capture and understand the queries access path which would highlight where the time is being spent. Are you working on Postgres?

If you're able to provide a copy of the database backup to Esri support, we would be more then willing to test and debug your specific issue - this would be very valuable.

Thank you and we look forward to helping you and address this issue - its definitely not our expectation that it would take this long to execute.

Thomas Brown
ESRI

Re: Feedback on the Prune Branch History Tool

SamDeLore — Wed, 24 Jun 2026 22:30:49 GMT

I ran a prune on our SQL DB a few months ago, after about 6 months of being live in production we'd noticed a distinct slow down on Isolation tracing.

But for us the biggest offenders were the various Subnetlines & UN_6_Topology. EID_Mappings did not change as we've not had to disable/enable in a production setting yet, but it's still a hefty table.

I did get a big drop in size, from around 35GB to 17GB. It's not the biggest database in the world but it's a decent percentage.

I'm wondering what others are doing for a DB Maintenance schedule?

Re: Feedback on the Prune Branch History Tool

PierreloupDucroix — Thu, 25 Jun 2026 00:10:35 GMT

Thanks everyone for your replies.

First, @RobertKrisher, I don't need to reclaim any disk space, so I agree with you; the allocated space can be kept for future database use. PostgreSQL's autovacuum should handle that if necessary.

@TomBrown, the main goal of this cleanup is precisely performance. Users are noticing a degradation in drawing performance over time (but not in subnet calculations), and we've had some bad experiences in the past with increasing the number of versions and archive rows. But that was with traditional versioning, so the comparison probably ends there. I understand that with this database size, it shouldn't be a problem.

Just one question: can the number of named versions impact performance, or is it only the number of archive rows?

Now, I'm going to focus more on attribute rules since many improvements were introduced in version 11.5.

The other main goal is to develop my skills and understand the mechanisms involved in pruning, in order to implement a version control and database management system that is effective in the long term.

I can provide a backup of the PostgreSQL database and add you to the support case for further testing.

Re: Feedback on the Prune Branch History Tool

Thomas_Brown — Thu, 25 Jun 2026 03:10:51 GMT

Good evening,

I’m still concerned users would be seeing any display performance degradation at this point, therefore it will be valuable to profile the spatial queries.

Answering your question… the number of versions has 0 impact on the performance of our queries, but as you highlight the historical rows “might” in the case of a poorly behaving application (query request).

we expect to support hundreds of thousands of versions (just as we did with traditional versioning). Of course there is a correlation between versions and the volume of edits in each version - thus the reason for having a version.

Performance is directly related to io and cpu consumed by any query. A reasonable spatial query returning a few hundred features should be extremely fast - as the access path is the spatial index followed by index scans to obtain the active row in the version.

of course if you have inefficient query requests which result in full table or index scans all bets are off and those queries need to be eliminated (fix the workflow or index attributes accordingly).

I would like to review your support incident. Please email me the incident number - tbrown@esri.com.

Postgres is a very important database we support and we want to ensure our queries are behaving as expected.

Thank you

Re: Feedback on the Prune Branch History Tool

Thomas_Brown — Thu, 25 Jun 2026 03:16:55 GMT

Hello Sam,

if you are seeing a slow down in an Isolation trace you should open a support incident for guidance. In server if you increase the logging level to verbose and perform the trace operation we log detailed statistics for the operation which will help explain where the time is being spent.

Not

knowing the columns of editing you’ve performed and the number of validates in the DEFAULT version you may actually need to disable and enable the topology to essentially reduce the number of pages accessed from the index to solve the trace operation - therefore improving performance.

Support can also provide guidance reviewing the logs.

Thank you

Re: Feedback on the Prune Branch History Tool

RobertKrisher — Thu, 25 Jun 2026 13:27:10 GMT

@SamDeLore tips for looking at logs to understand performance:

Utility Network Diagnostics

Parsing Utility Network Diagnostic Logs

Re: Feedback on the Prune Branch History Tool

SamDeLore — Fri, 26 Jun 2026 06:25:17 GMT

Thanks @RobertKrisher, I'll have a read through your links

Re: Feedback on the Prune Branch History Tool

SamDeLore — Fri, 26 Jun 2026 06:52:27 GMT

Thanks for the tip @Thomas_Brown, makes sense - we've had substantial editing volume since the network was originally built, so after many topology validations I'd imagine the pages are a bit of a mess by now.

I have a backlog of schema and network rule changes queued up, so it's a good opportunity to bundle those in and get it all done in one window with a prune as well.

Re: Feedback on the Prune Branch History Tool

VishApte_NGIS — Thu, 02 Jul 2026 02:17:15 GMT

Thanks @PierreloupDucroix for sharing the statistics. We are looking to prune the archived data in near future. We are contemplating whether we should only prune system tables (UN_6_* tables) or all objects.

We are in a similar situation and some of our tables have grown enormously since going live, even if we didn't add much new asset data. In particular UN_6_EIDMAPPINGS , SUBNETWORKS* and ElectricJunction have grown with approx. 10% of the data as current, rest as archived. We have had to disable and enable topology to fine tune our connectivity and association rules over the period. So growth in UN_6_EIDMAPPINGS and SUBNETWORKS table is understandable. And we have a process to link electric junctions representing customer connection point to Customer Information Systems that causes some continuous edits.

Cheers,

Vish

Re: Feedback on the Prune Branch History Tool

VishApte_NGIS — Thu, 02 Jul 2026 02:22:00 GMT

Hi @PierreloupDucroix , did the data editing, validating and network tracing workflows experience performance improvement after pruning? If so, can you please indicate the magnitude?

Cheers,

Vish

Re: Feedback on the Prune Branch History Tool

PierreloupDucroix — Thu, 02 Jul 2026 03:32:46 GMT

Hi, we were in the same situation, with an EID_mapping table that was growing due to changes in the UN model and other tables synchronized with a client system (this explains why electricjunctionobject is the second-largest table in my table).

Following my support ticket, the Esri team was very responsive and identified possible improvements in pruning the system tables. I don't have much more information to share, but I would recommend waiting for a patch if you're using PostgreSQL (I don't know if other DBMSs are affected). That said, if you prune at night (don't do it in your garden ;-)) or test in a staging environment, it shouldn't necessarily be a problem.

Regarding performance improvements, I'm still analyzing the potential gains, but they're offset by the upgrade to 11.5 + the database pruning + the improved attribute rules. My current opinion is that the gains in data entry will be more substantial through improved efficiency of attribute rules. Gains in terms of tracing, subnet export, etc., still need to be validated, but I will not hesitate to share my results.

Re: Feedback on the Prune Branch History Tool

SamDeLore — Sun, 05 Jul 2026 22:31:59 GMT

Hi @VishApte_NGIS,

In our case a prune and Index / statistics cleanup did improve tracing performance. We had traces getting timed out by our load balancer at 60 seconds and this brought them back under the timeout to around 20 seconds.

I'm sure we'll regain more performance with a disable / enable topo cycle as well as we haven't done one in over 12 months

Re: Feedback on the Prune Branch History Tool

RobertKrisher — Mon, 06 Jul 2026 01:51:40 GMT

@SamDeLore a >3x gain in performance from tracing is a lot more than what we would expect to see and implies that there may be something else that needs reviewed/tuning in your environment. @TomBrown ?

Re: Feedback on the Prune Branch History Tool

SamDeLore — Mon, 06 Jul 2026 02:11:22 GMT

Agree, it blew out probably 5x or more to get above the timeout, then roughly 3x reduction with the prune / index rebuilds. I don't think the fundamental issue was solely the archiving bloat, but either the prune and/or index work brought it back to functional to stop the timeouts in PROD.

Worth noting this was only happening with Isolation traces on very large and complex subnetworks.

I'm preparing for another round of maintenance now, I'll include a disable/enable topo this time but if there's any other recommendations then I'm keen to explore. (UN:7, 11.3 (11.5 egdb), SQL Server 2019)

Is there any significance of running Update Is Connected other than the obvious?

Re: Feedback on the Prune Branch History Tool

Thomas_Brown — Mon, 06 Jul 2026 10:42:33 GMT

Sam,

20 seconds is still extremely slow (but still dependent on how many features are being traced). For 20 seconds, hundreds of thousands?

A typical subnetwork trace for an electric distribution circuit, three seconds (10-15K features). Large pressure zones (50K features maybe 10 seconds).

The only way to understand is by placing the server logs in verbose or debug mode, perform the trace and extract the instrumentation which will highlight each step of the trace operation (note this will not include the time after the trace completes and the Pro client receives the results and selects the features to display, it’s the time to solve the trace itself).
If you need further guidance I strongly recommend a support case where we can provide better support and recommendations if necessary.
Please let us know.

Tom

Re: Feedback on the Prune Branch History Tool

RobertKrisher — Mon, 06 Jul 2026 13:22:23 GMT

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.

Re: Feedback on the Prune Branch History Tool

VishApte_NGIS — Fri, 24 Jul 2026 01:13:13 GMT

@SamDeLore

In my experience, isolation trace is always slower than all other trace types, especially in water networks where the pressure system is very looping and a location in a network has many possible paths to the subnetwork controller(s). Water Network Isolation trace in a CBD area of a large city of Australia takes about 45 to 75 seconds. And this is a brand new UNM model with no history. Same trace type in a rural area takes less than 10 seconds and traces more features. It is just a nature of the trace.

All other trace types in my experience takes less than 10 seconds including Water, Sewer and Electric networks, for a reasonably speced database and server.

Cheers,

Vish

Re: Feedback on the Prune Branch History Tool

SamDeLore — Fri, 24 Jul 2026 05:01:37 GMT

Thanks @VishApte_NGIS.

I'm seeing the same, we have a few very large pressure networks with loops everywhere that take around 25s. The initial upstream trace returns 94k features if run on its own, and the whole isolation trace operation traverses 308757 elements. It's feeling like the network is just big and there aren't many directional elements to rely on to easily interpret flow direction.

It was around 30s before running disable / enable topo and cleaning up the indexes. Breakdown below

Smaller networks I'm seeing from 400ms to 2s.

Step 1: Load configuration, locations, and attributes (0.007 seconds)

Step 2: Propagation [values propagated from 0 controllers] (0.000 seconds)

Step 3: Perform upstream trace before filtering, validate consistency, setting results, etc. (15.063 seconds)

Trace initial tier (15.057 seconds)

Trace additional tiers (0.000 seconds)

Calculate flow directions (14.420 seconds)

Query adjacencies (4.153 seconds)

Apply functions (0.000 seconds)

Check condition barriers (0.716 seconds)

Check function barriers (0.000 seconds)

Check propagator filters (0.000 seconds)

Check is controller (0.000 seconds)

Get asset info (0.032 seconds)

Traverse across controllers (0.027 seconds)

Skip directional traversal (0.207 seconds)

Check internal edges (0.000 seconds)

Validate controllers (0.000 seconds)

Query 'from' 'to' junctions (3.531 seconds)

Filter bitset (0.000 seconds)

Step 4: Apply filters (0.015 seconds)

Step 5: Exclude barriers (0.000 seconds)

Step 6: Get info from result types (0.000 seconds)

Step 7: Prefetch connectivity results (0.022 seconds)

Step 8: Update function results (0.000 seconds)

Step 9: Validate locatability (0.000 seconds)

Step 10: Prefetch association results (0.000 seconds)

Step 11: Include associations (0.000 seconds)

Get association info (0.000 seconds)

Get network source ID (0.000 seconds)

Check is spatial (0.000 seconds)

Step 12: K-nearest neighbors (0.000 seconds)

Step 13: Apply output filters (0.000 seconds)

Step 14: Validate consistency (9.092 seconds)

Get dirty areas (0.053 seconds)

Use heuristic - convert dirty areas to elements instead of converting elements to global IDs (0.000 seconds)

Do not use heuristic - convert trace result elements to global IDs (8.913 seconds)

Check associations (0.025 seconds)

Step 15: Convert result network elements into features and get weights (0.009 seconds)

Get global IDs and oids for elements (0.000 seconds)

Get weights for elements (0.009 seconds)

Step 16: Aggregate geometries (0.000 seconds)

Step 17: Get connectivity (0.000 seconds)

Step 18: Get feature elements (0.011 seconds)

Step 19: Get associations (0.000 seconds)

Step 20: Get network source mapping (0.000 seconds)

Step 21: Get index statistics (0.001 seconds)

Total # Traversed Elements: 308757 (including 308757 Junction/Edge Elements and 0 Associations), # Junction Result Elements: 2, # Edge Result Elements: 0 (including 0 Connectivity Associations)

Total Trace Time (24.222 seconds)

@Thomas_Brown , @RobertKrisher