Register a Feature Class with Geodatabase slow

[DavidGeorge]

Can anyone advise exactly what processes ArcGIS Pro 2.4.2 does when running the Register with Geodatabase tool?

I'm registering a spatial table within the enterprise geodatabase and it is taking a long, long time. The table does have several million features (polygon) which are all spatially referenced.

The database is Postgres 10.11 with PostGIS 2.4, the geometry column and objectid column are both indexed (GIST and B-Tree) and all of the geometries are spatially referenced to the correct coordinate system,

What is ArcGIS Pro doing that is making it slow. Is there a way to make it go faster?

To get a fuller understanding is there an explicit list of functions/procedures that the Register with Geodatabase tool executes as the documentation here is rather muted?

[George_Thompson]

I do not think that it is doing anything else outside of what the documentation mentions. It adding an ArcGIS managed ObjectID and registering the table with the correct enterprise geodatabase system tables. This may require it to scan the table and look for all the spatial data needed in the system tables.

How long is "a long, long time"?

How many features?

Can you try a spatial table with less features for a test?

What is the geometry being used, I am guessing PG_Geometry (PostGIS) correct?

Where is the Postgres DB in relation to the ArcGIS Pro client? Same building, etc.?

[DavidGeorge]

The table contains in total 122,794,859 rows. The table took 15:55 hrs to register. 15:13 of which were down to the following queries being executed:

CREATE UNIQUE INDEX r25_sde_rowid_uk on area (objectid)  WITH (FILLFACTOR = 75)	05:10
SELECT ST_xmin(b1.bnd), ST_ymin(b1.bnd), ST_xmax(b1.bnd), ST_ymax(b1.bnd), ST_zmin(b1.bnd), ST_zmax(b1.bnd), 0, 0  FROM (SELECT ST_3Dextent(sde.area.shape)::Box3d FROM sde.area ) AS b1 (bnd)	03:32
SELECT COUNT(*) FROM sde.area WHERE shape IS NOT NULL	03:29
SELECT MIN(ST_xmin(shape)), MIN(ST_ymin(shape)), MAX(ST_xmax(shape)), MAX(ST_ymax(shape)), MIN(ST_zmin(shape)), 0, MAX(ST_zmax(shape)), 0 FROM sde.area WHERE shape is NOT NULL	03:02

1. What I don't understand is why ArcGIS decided to delete a perfectly good existing b-tree index on the objectid column (int, notnull)! This made the process run 5 hours longer than it needed too.
2. Why did ArcGIS need to execute 3 queries to calculate the full extents of the table, surely only one would have sufficed? Again this made the process run 6 hours longer than it really needed to.
3. Whilst the Register with GeoDatabase documentation state if the dataset being registered contains existing features, the extent of the existing features will be used. This obviously a time-consuming task with such a large dataset, if you already know the full extents of the data, you should be able to manually specify the extents if they are known, but this only seems to apply if the table is empty.
4. It also appears that ArcGIS renamed the existing spatial index from area_shape_1582215224548 to r27_sde_rowid_uk - not sure why the was necessary?

The PostGIS database is hosted in Azure and the Geoprocessing tasking is being executed from a Windows 10 virtual machine hosted in Azure

[George_Thompson]

Based on that information, I would work with tech support to better understand the behavior and see if there is anything that could be done to speed up the process..