Demora excesiva en Reporte de Alumnos por Actividad Académica

Hola gente soy yo de nuevo con una consulta que demora… (3 minutos)
Esta vez en la operacion Reporte de Alumnos por Actividad Académica

SET SCHEMA 'negocio';

DROP TABLE _Tactividades_aux;

DROP TABLE _Tactividades;

DROP TABLE _temp_prop_alumno;

DROP TABLE _temp_relacion;

-- Actividades realizadas por el alumno
CREATE TEMP TABLE _Tactividades_aux (
  elemento INTEGER,
  id_acta INTEGER,
  origen CHAR(1),
  equivalencia_tramite INTEGER,
  equivalencia INTEGER,
  fecha DATE,
  escala_nota INTEGER,
  nota VARCHAR(10),
  resultado CHAR(1),
  promediable CHAR(1)
);

CREATE TEMP TABLE _Tactividades (
  elemento INTEGER,
  id_acta INTEGER,
  origen CHAR(1),
  equivalencia_tramite INTEGER,
  equivalencia INTEGER,
  fecha DATE,
  escala_nota INTEGER,
  nota VARCHAR(10),
  resultado CHAR(1),
  promediable CHAR(1)
);

-- Propuesta del alumno (Incluye propuestas vinculadas)
CREATE TEMP TABLE _temp_prop_alumno (
  alumno INTEGER,
  propuesta INTEGER,
  plan INTEGER,
  plan_version INTEGER
);

CREATE TEMP TABLE _temp_relacion (relacion INTEGER);

-- Tabla de propuestas relacionadas";
SELECT
  vw_personas.apellido_nombres AS apellido_y_nombres,
  vw_personas.tipo_nro_documento AS documento_principal,
  sga_alumnos.persona,
  sga_alumnos.alumno,
  sga_alumnos.legajo,
  sga_alumnos.propuesta,
  sga_alumnos.calidad,
  sga_alumnos.regular,
  f.promedio,
  f.promedio_sin_aplazos,
  f.cant_actividades_aprobadas,
  f.cant_actividades_plan,
  TO_CHAR (f.fecha_ultimo_examen, 'DD/MM/YYYY') AS fecha_ultimo_examen,
  vw_planes.propuesta_nombre AS propuesta_nombre,
  vw_planes.propuesta_codigo AS propuesta_codigo,
  '('||vw_planes.propuesta_codigo||') '||vw_planes.propuesta_nombre AS propuesta_descr,
  vw_planes.plan_nombre AS plan_nombre,
  vw_planes.plan_codigo AS plan_codigo,
  vw_planes.version_nombre AS plan_version_nombre,
  vw_planes.version_codigo AS plan_version_codigo,
  sga_ubicaciones.nombre AS ubicacion_nombre,
  sga_alumnos.ubicacion,
  sga_propuestas_aspira.anio_academico AS anio_academico_ingreso,
  TO_CHAR (
    get_fecha_ingreso_alumno (sga_alumnos.alumno),
    'DD/MM/YYYY'
  ) AS fecha_ingreso,
  (
    SELECT
      r.anio_academico
    FROM
      sga_reinscripciones AS r
    WHERE
      r.alumno=sga_alumnos.alumno
    ORDER BY
      r.anio_academico DESC
    LIMIT
      1
  ) AS ultima_reinscripcion,
  COALESCE(
    (
      SELECT
        mdp_personas_contactos.email
      FROM
        mdp_personas_contactos
      WHERE
        mdp_personas_contactos.persona=vw_personas.persona
        AND contacto_tipo IN ('MP', 'MS', 'MI')
      ORDER BY
        contacto_tipo='MP' DESC,
        contacto_tipo='MS' DESC,
        contacto_tipo='MI' DESC
      LIMIT
        1
    )
  ) AS email,
  COALESCE(
    (
      SELECT
        (
          mdp_personas_contactos.telefono_codigo_area||'|'||mdp_personas_contactos.telefono_numero
        )
      FROM
        mdp_personas_contactos
      WHERE
        mdp_personas_contactos.persona=vw_personas.persona
        AND contacto_tipo IN ('C', 'F', 'T', 'L')
      ORDER BY
        contacto_tipo='C' DESC,
        contacto_tipo='F' DESC,
        contacto_tipo='T' DESC,
        contacto_tipo='L' DESC
      LIMIT
        1
    )
  ) AS nro_telefono
FROM
  sga_alumnos
  JOIN vw_personas ON sga_alumnos.persona=vw_personas.persona
  JOIN sga_propuestas_aspira ON (
    sga_propuestas_aspira.persona=sga_alumnos.persona
    AND sga_propuestas_aspira.propuesta=sga_alumnos.propuesta
  )
  JOIN sga_situacion_aspirante ON (
    sga_situacion_aspirante.situacion_asp=sga_propuestas_aspira.situacion_asp
    AND sga_situacion_aspirante.resultado_asp IN ('A', 'P')
  )
  JOIN vw_planes ON vw_planes.plan_version=sga_alumnos.plan_version
  JOIN sga_ubicaciones ON sga_alumnos.ubicacion=sga_ubicaciones.ubicacion
  JOIN LATERAL get_promedios_actividades_alumno (
    sga_alumnos.alumno,
    sga_alumnos.plan_version,
    FALSE
  ) AS f ON TRUE
WHERE
  sga_propuestas_aspira.anio_academico='2021'
  AND f.cant_actividades_aprobadas>='1'
  AND sga_alumnos.propuesta IN (
    SELECT
      propuesta
    FROM
      sga_propuestas_ra
    WHERE
      responsable_academica='12'
  )
ORDER BY
  vw_planes.propuesta_nombre,
  sga_ubicaciones.nombre,
  vw_personas.apellido,
  vw_personas.nombres

En linea con otras soluciones que me han brindado, probé reemplazando las vistas vw_personas y vw_planes por sus correspondientes tablas, pero esta vez no tuve mejora en tiempo de ejecución, más bien lo contrario.

Muchas graciass

Emiliano, en que version estan? Porque sobre ese reporte se habia realizado un cambio para mejorar los tiempos de respuesta.

No te pregunté la version en este foro. Seguramente estan en una version anterior a 3.21.0

Pasa lo mismo en una base de test copia de la de producción?

Que filtros son los que ingresas en el reporte?

  • Ingreso año = 2021
  • Cantidad de actividades aprobadas >= 1
    -Reponsable academica = 12

¿Son esos los unicos filtros que aplicaste?

Seguramente son muchos los alumnos a procesar. Sacaste la cuenta de cantidad de alumnos que son de las propuestas de esa responsable academica?
¿Podes ver de ajustar la busqueda, procesar por ejemplo para una propuesta?

¿Porque necesitan buscar todos los alumnos ingresantes 2021, de una facultad supongo, que tengan al menos una actividad aprobada ?

Fijate ademas que datos agregan al reporte. Por ejemplo promedio si no es necesario no lo agregues, asi con cualquier dato que necesite un procesamiento para obtenerlo.

Alejandro,
Estamos en la version 3.20 y sí, pasa tanto en producción como en test/local/desarrollo

Los filtros aplicados son esos que listaste, nada más ni nada menos. Y si, entiendo que es un conjunto de alumnos muy grande. Más allá de alguna optimización de la propia consulta ¿no seria conveniente poner como obligatorios otros elementos del filtro como propuesta, plan, ubicacion; para asi achicar un poco la cantidad de registros y acelerar la ejecución?

La verdad desconozco en este momento qué información necesitan del reporte. Yo solo tomé la consulta SQL pelada que apareció en el log de postgres demorando una eternidad. Puedo averiguar qué necesitan, tal vez es mucho menos info de la que tira el reporte.

¿no seria conveniente poner como obligatorios otros elementos del filtro como propuesta, plan, ubicacion; para asi achicar un poco la cantidad de registros y acelerar la ejecución?
Estamos en un dilema con temas como este. Tu institucion tiene miles de alumnos, pero hay otras con pocos alumnos y si ponemos esos filtros obligatorios diran, sacalos que complica porqe debemos realizar varias consultas. Entonces no hay algo que deje conformes a todos (institucion con pocos alumnos o a una con muchos)

Tal vez en este caso debieran personalizar el filtro y hacer obligatorio esos campos.

Sucede lo mismo por ejemplo en la operación de “Detección de posibles egresados”. Hay ciertas operaciones que el conjunto a evaluar son todos los alumnos activos y según filtros que hayan ingresado (responsable académica, propuesta, plan, ubicacion, año de ingreso, etc…)

Son reportes u operaciones puntuales que deberán poner el foco y ver de personalizar el filtro de busqueda para achicar el conjunto de alumnos a verificar para que el proceso se realice (finalice) y sea en tiempos razonables.

Igualmente esto no quita que sigamos mejorando estas operaciones respecto del tiempo en que tarda en devolver el resultado.