Very sluggish Topology, Postgres Table Shows 1.6 million rows in the t_1_dirtyareas table

[MichaelSnook]

Hello

I have been trying to troubleshoot ongoing slowness with our enterprise parcel fabric topology.  The dirty areas table has been validated but the table in ArcGIS Pro shows about 6500 rows (all of which show isretired = 1).  Looking at the table in PGAdmin, it shows about 1.6 million rows.  I can't help but think that has something to do with the sluggishness but there doesn't seem to be any documentation about it.

Is that intended behavior to keep all of those rows (both in the Pro view and Postgres?)  Any suggestions for improving the performance here would be greatly appreciated!

Thanks

[RobertKrisher]

Because you are using branch versioning, all your tables have archiving enabled. If you look at the table in the backend you will see all the historical dirty areas in addition to the active dirty areas.

[NateArnold]

Hopefully arcpy.management.PruneBranchHistory will support parcel fabric at 3.7.  I missed the beginning of yesterday's webinar and they haven't posted it yet.

[NateArnold]

Help is on the way at 3.7 - https://community.esri.com/t5/arcgis-parcel-fabric-videos/meetup-parcel-fabric-what-s-new-in-arcgis-...

[RobertKrisher]

Take a look at the spatial index on the dirty areas table, I have seen quite a few instances where the spatial index needs to be recalculated in order to improve performance. Pruning rows can help mitigate a bad spatial index or an undersized environment.