Hola
Tanto en la versión 3.20.0 como en la 3.22.1, en la operación:
» Reconocimiento de Actividades » Equivalencias »Rectificar Equivalencia
Al querer agregar una nueva rectificación y buscar por apellido y Nº resolución, el sistema tarda de manera excesiva y se termina colgando.
El inconveniente aparece cuando se añade el filtro “Nº Resolución”. Si ese filtro no se carga, responde enseguida. Pero al querer usar el filtro de resolución se cuelga el sistema.
Saludos.
Buen día Iris,
hicimos unas pruebas en nuestro ambiente y no nos sucede lo que reportas. Si aplicas la búsqueda sólo por el Nro de resolución te muestra resultados?
Podrías enviarnos los logs de al momento de aplicar la búsqueda por los filtros que hacen que se cuelgue el sistema.
Saludos
Hola Stella
No lo había probado usando solamente el filtro del Nº Resolución. En ese caso también responde rápido.
El problema de la demora excesiva (y en la mayoría de los casos hasta se cuelga) es cuando se completan ambos filtros, tanto “Apellido y Nombre” como “Nº Resolución”.
Te paso el log (en este caso demoró muchísimo, pero respondió, tal vez por probarlo en un entorno local)
Rectificar_Equivalencia.log (24,6 KB)
Gracias
Hola Iris, por favor saca la consulta de la linea 354, ejecutala en al base y fijate si es esa la consulta que tarda mucho tiempo.
Si es la que tarda, luego reemplaza el FROM-WHERE por lo siguiente:
FROM sga_equiv_tramite
JOIN sga_equiv_tramite_origen ON sga_equiv_tramite_origen.origen = sga_equiv_tramite.origen
JOIN sga_equiv_tramite_estados ON sga_equiv_tramite_estados.estado = sga_equiv_tramite.estado
JOIN sga_alumnos ON sga_equiv_tramite.alumno = sga_alumnos.alumno
JOIN vw_personas ON sga_alumnos.persona = vw_personas.persona
JOIN sga_planes_versiones ON sga_planes_versiones.plan_version = sga_equiv_tramite.plan_version
JOIN sga_planes ON sga_planes.plan = sga_planes_versiones.plan
JOIN sga_propuestas ON sga_propuestas.propuesta = sga_planes.propuesta
LEFT JOIN sga_documentos ON sga_equiv_tramite.documento = sga_documentos.documento
LEFT JOIN sga_instituciones ON sga_equiv_tramite.institucion = sga_instituciones.institucion
WHERE sga_equiv_tramite.equivalencia_tramite NOT IN
(SELECT sga_equiv_tramite.rectifica_a
FROM sga_equiv_tramite
WHERE sga_equiv_tramite.rectifica_a IS NOT NULL AND
sga_equiv_tramite.estado = 'A')
AND f_limpiar_acentos(vw_personas.apellido || vw_personas.nombres::varchar) ILIKE '%Sanchez%'
AND f_limpiar_acentos(sga_documentos.documento_numero::varchar) ILIKE '%393/2022%'
AND
/*-------- PERFIL DE DATOS --------*/
(sga_planes.propuesta) IN
( SELECT toba_pdtasoc_1.propuesta
FROM vw_ug_propuestas toba_pdtasoc_1
FROM vw_ug_propuestas toba_pdtasoc_1
WHERE ( toba_pdtasoc_1.unidad_gestion IN ('12') )
)
ORDER BY sga_equiv_tramite.equivalencia_tramite
Podes probar sin los filtros por apellido o sin usar la funcion “f_limpiar_acentos”, tanto en la busqueda por apellido/nombre del alumno como enla otra por el nro de resoluciòn.
Tambien con/sin el filtro por el perfil de datos.
Esperamos tus pruebas y resultados.
Saludos
Hola Alejandro
Si, esa la consulta que tarda demasiado.
La función “f_limpiar_acentos” no afecta en nada. No cambia nada el hecho que esté o no.
Lo que noto es que si la ejecuto con estas ambas condiciones, el tiempo de respuesta en una base local supera los 15 minutos:
AND f_limpiar_acentos(vw_personas.apellido || vw_personas.nombres::varchar) ILIKE '%Sanchez%'
AND f_limpiar_acentos(sga_documentos.documento_numero::varchar) ILIKE '%393/2022%'
Pero si la ejecuto con una sola de esas condiciones (cualquiera, pero no ambas a la vez) el tiempo de respuesta es de 2-3 segundos.
Probando reemplazar el FROM-WHERE con algo similar a lo que enviaste, el tiempo es de unos 2 seg. Me dio error de sintaxis el sector del perfil de datos que pasaste. Lo corregí así:
/*-------- PERFIL DE DATOS --------*/
(sga_planes.propuesta) IN
( SELECT toba_pdtasoc_1.propuesta
FROM vw_ug_propuestas toba_pdtasoc_1
WHERE ( toba_pdtasoc_1.unidad_gestion IN ('12') )
)
Gracias!!
Saludos
Crea el siguiente indice, y volves a probar con las dos condiciones:
CREATE INDEX id_sga_documentos_documento_numero ON sga_documentos (documento_numero);
Hola Alejandro
La creación del índice mejoró un poco el tiempo de respuesta, pero sigue demorando bastante. Tardó como 3 minutos en proyectar el resultado.
No hay como la eficiencia de los JOIN! (sólo 2 segundos en dar la misma respuesta)
Gracias
Iris, no entendi al final. Las pruebas las haces con la query original, o con las modificaciones en el FROM y WHERE, pasando todos las condiciones del where al from?
Porque postgres es lento en querys donde hay left joins y estos no estan al final de la lista de tablas del from. Originalmente esta query tiene dos left join al comienzo y luego siguen otras tablas y con todas las condiciones de join en el where.
Creamos el ticket 49978 para version 3.23.0 con estos cambios. Por si queres aplicarlos carga una solicitud y te enviamos el archivo que modificamos asi podes replicar las querys en tu instalacion.
Saludos.
Hola Alejandro
Me refería a que creando el índice sobre el campo documento_numero de la tabla sga_documentos, el tiempo mejora un poco, pero no mucho, sobre la consulta original que tiene el sistema (con los LEFT JOIN al principio y el producto cartesiando luego con las restantes tablas /vistas). Sigue siendo un tiempo de respuesta elevado. Varios minutos.
La consulta modificada con todos JOIN, dejando los LEFT JOIN al final es realmente muchisimo más eficiente. Sólo demora 1-2 seg.
Gracias por incorporar esta mejora en nueva versión.
Saludos
Bien Iris, entendido. Si en el sistema en las ultimas versiones fuimos adecuando las querys con los joins en el from y pasando al final de la lista de tablas los left joins. Eso mejora muchisimo los tiempos de respuesta. Pero como vemos algunas aun quedan, gracias por avisar y seguir mejorando los tiempos de respuesta de las consultas a la base.