Demora excesiva en Ficha de la Persona > pestaña Optativas

Buenas,

Estamos teniendo problemas de performance general con las operaciones ejecutadas desde Gestion. Por alertas de consultas demorando más de 1 minuto, comenzamos a buscarlas en el log y analizarlas individualmente. Una de ellas es la que dispara la operacion de Ficha de la Persona > Optativas


	SELECT elemento,
        	Aprobada' as tipo,
               	1 as orden
	FROM vw_hist_academica_basica
        JOIN sga_alumnos ON sga_alumnos.alumno = vw_hist_academica_basica.alumno
       WHERE sga_alumnos.persona = 10606
      	AND resultado = 'A'
UNION 
	SELECT elemento,
       		'Regularizada' as tipo,
                2 as orden
      	FROM vw_regularidades_basica 
       	JOIN sga_alumnos ON sga_alumnos.alumno = vw_regularidades_basica.alumno
        WHERE sga_alumnos.persona = 10606
       	AND es_vigente = 1
        AND resultado = 'A'
UNION 
	SELECT c.elemento, 'En curso' as tipo, 3 as orden 
       	FROM sga_insc_cursada as i 
       JOIN sga_alumnos ON sga_alumnos.alumno = i.alumno 
      	JOIN sga_comisiones as c ON c.comision = i.comision 
       	JOIN vw_periodos_lectivos as pl ON pl.periodo_lectivo = c.periodo_lectivo
       WHERE sga_alumnos.persona = 10606 AND pl.fecha_fin >= CURRENT_DATE 
      	AND    (c.elemento) IN
                            ( SELECT toba_pdtasoc_4.elemento
                             FROM vw_ug_elementos toba_pdtasoc_4
                             WHERE  ( toba_pdtasoc_4.unidad_gestion IN ('15') OR toba_pdtasoc_4.unidad_gestion IN ('24') ) )
ORDER BY 1, 3

con una duración de 46 segundos

Por las pruebas que estuvimos haciendo, el problema parece estar en la vw_hist_academica_basica y su JOIN con sga_alumnos

El explain nos tira;

#	Node												Timings				Rows			Loops
													Exclusive	Inclusive	Rows X	Actual	Plan
1.	 Hash Inner Join (cost=3279.94..381658.54 rows=3 width=40) (actual=962.73..46045.588 rows=55)
		Hash Cond: (alu2.alumno = sga_alumnos.alumno)						639.14 ms	46045.588 ms	↓ 18.34
2.	 Append (cost=3276.34..378090.02 rows=282369 width=263) (actual=41.823..45405.99 rows=2639658)	582.971 ms	45405.99 ms	↓ 9.35	2639658	282369	1
3.	 Result (cost=3276.34..273934.97 rows=91804 width=215) (actual=41.821..29580.871 rows=1961804)	886.494 ms	29580.871 ms	↓ 21.37	1961804	91804	1
4.	 Append (cost=3276.34..272787.42 rows=91804 width=213) (actual=41.818..28694.377 rows=1961804)	419.764 ms	28694.377 ms	↓ 21.37	1961804	91804	1

Alguna aiuda?? Muchas gracias!

Hola Emiliano, cual es la version en producción?

Si cambias:

SELECT elemento,
        	Aprobada' as tipo,
               	1 as orden
	FROM vw_hist_academica_basica
        JOIN sga_alumnos ON sga_alumnos.alumno = vw_hist_academica_basica.alumno
       WHERE sga_alumnos.persona = 10606
      	AND resultado = 'A'

por:

SELECT elemento,
        	Aprobada' as tipo,
               	1 as orden
	FROM vw_hist_academica_basica
         WHERE persona = 10606
      	AND resultado = 'A'

¿El resultado mejora y devuelve los mismos registros?

¿Esta persona en cuantas propuestas se encuentra?


Lo mismo con la 2da consulta respecto de las regularidades:

SELECT elemento,
       		'Regularizada' as tipo,
                2 as orden
      	FROM vw_regularidades_basica
       	JOIN sga_alumnos ON sga_alumnos.alumno = vw_regularidades_basica.alumno
        WHERE sga_alumnos.persona = 10606
       	AND es_vigente = 1
        AND resultado = 'A'

por:

SELECT elemento,
       		'Regularizada' as tipo,
                2 as orden
      	FROM vw_regularidades_basica
        WHERE persona = 10606
       	AND es_vigente = 1
        AND resultado = 'A'

hola Alejandro!
Estamos en la version 3.20.1

Haciendo las modificaciones que sugeriste, eliminando la tabla sga_alumnos, los tiempos bajan completamente a valores normales. Y los resultados son los mismos.
Esta persona en particular es alumno de 2 propuestas.
¿puede ser el modo en que arma la planificación el motor de postgres? ¿algun indice?

muchas gracias

Ok. Ya creamos ticket #45251 (version 3.22) para hacer este cambio y otro respecto al perfil de datos (que se agrega en la 3er Select) en esa consulta de las actividades aprobadas, regularizadas y las que esta cursando actualmente.
Esta demora lo habiamos visto en otros reportes, por ejemplo en el de historia academica de la Ficha de la persona. Si es algún tema con como Postgres planifica la ejecución del a query. Indices estan, fijate que accede por el dato “alumno”

Perfecto. Nosotros podríamos entonces modificar provisoriamente el método que genera esa consulta con esos cambios que sugeriste, luego buscar otras consultas donde se replique ese cruce y ver si también se produce esta demora.

Si pueden aplicarlo temporalmente hasta que se pasen a la version en que esta modificación sea incluida.
Si lo detectan en algun otro lugar, nos avisan y lo vemos.
Gracias!