¿Cómo mejorar el rendimiento de la geometría de ArcGIS Desktop 10.2.2 y Postgres 9.2?

Question

Estoy experimentando graves problemas de rendimiento en un featureclass polígono (PG_GEOMETRY) en una base de datos PostgreSQL 9.2 de un cliente 10.2.2. Incluso cuando el zoom a un área con 10-20 características dentro de la extensión.

Lo he reducido a una llamada de ArcGIS Desktop: DECLARE sdecur_508_23777 BINARY CURSOR WITH HOLD FOR select st_asewkb(ST_setSRID(zzzztablenamezzzz.shape,-1)) AS shape from sde.fooschema.zzzztablenamezzz y luego las búsquedas posteriores (por ejemplo 2015-03-13 19:52:26 GMT LOG statement: FETCH FORWARD 1000 from sdecur_508_23777 )

El marco de datos y el identificador de referencia espacial (54017) son los mismos, así que no veo por qué hay que ejecutar una consulta que devuelva toda la geometría de la tabla como WKB sin SRID (cuenta aprox. 900000 polígonos).

No hay ningún tipo de renderizado extravagante: sólo he añadido la featureclass y he hecho un pequeño zoom. El featureclass tiene un índice espacial que funciona bien

Answer 1

Si esa es la consulta que se utiliza, supongo que no tiene suerte.

¿No existe la cláusula DÓNDE?

Nunca he jugado con los cursores, pero según entiendo la consulta, Arc-whatever recupera 1000 filas a la vez de todo el conjunto de datos.

No importa lo eficiente e inteligente que sea Arc-whatever entonces para averiguar qué geometrías utilizar y renderizar. Todo el rendimiento ya está perdido.

Todas las partes de todas las geometrías tienen que ser detonadas en la base de datos. Luego PostGIS tiene que convertir cada una de las 900000 geometrías en EWKB. Eso es un montón de iteraciones y memorias.

Así que espero que haya alguna parte más de la consulta que falte.

La forma correcta de hacerlo es, por supuesto, dejar que PostGIS haga un escaneo de índices espaciales y sólo maneje las filas que se necesitan.