ST_GEOMETRY seems awfully slow at unpacking coordinate data via the stardard SHAPE.points function given the quantity of data. I've performed queries that don't even use the st_envintersects operator (the one causing inappropriate Full Table Scans). I just do a WHERE OBJECTID between, say, 1 and 10. So the access path is via a non-spatial index. None of the features have an excessive number of vertices. Again, simply unpacking coordinates itself seems slow. It's even slower using extproc and the sde.st_astext(shape) function. But my focus is plain vanilla SHAPE.points querying (the type of query submitted by ArcGIS Explorer 1500).
Q1) Has anyone tested performance using the old SDE (COMPRESSED) BINARY--the BLOB spatial data type? I'd at least like to prove that ST_GEOMETRY is the villain (if that's the case)--and that we could switch to SDE BINARY as a work-around. This would be for our publishing SDE instance--one we're not even using exproc SQL spatial functions in. We'd like to keep using ST_GEOMETRY for our editing instance.
Q2) Has anyone temporarily reverted to SDE BINARY due to performance performance problems with ST_GEOMETRY?
Q3) Does anyone have a test query for returning coordinate data from a feature class in SDE BINARY format? Imagine I'd have to join the business table with its associated F-table via the b-table's SHAPE column FK.
With ST_GEOMETRY now being the default spatial data storage type, it's clear this is the focus of present and future development. So I'm confident things will continue to improve. But for now, I have a performance issue to contend with.
I'd love to see if there's any difference in speed executing queries in SQL*PLUS between the same feature class with one in ST_GEOMETRY and one in SDE BINARY. Switching to SDE BINARY alone may be worthwhile if it gets rid of Full Table Scans.
I'm relucant to tweak statistics gathering or modify the st_envintersects operator in order to get around the FTS issue. Could create problems with future upgrades. Although again, with the particular query I'm testing, I'm not getting FTSes. Just "slow" (or what seems slow to me anyway) retrieval of coordinates.
System details:
* We're running ArcSDE 9.3.1 (no service packs yet) on an Oracle 10.2.0.3 instance
* OS is Redhat Linux)
* Our Oracle clients are at 11g
* During testing, Oracle is not breaking a sweat. The slow performance is with a single user querying the instance. The SGA is properly sized--nothing's getting aged-out. Subsequent runs of the test query perform about the same.
Things seem slow even in a best case scenario baseline like I've described above. So could the unpacking of ST_GEOMETRY coordinate data be a sort of "hidden" bottleneck? No other components of the system show any stress.
Hope this all makes sense.