Si quieres ajusta el sar para tomar muestras de 1 min para descartar que los
discos estén saturados.
Sobre la versión vieja de postgresql hace un set de pruebas debería funcionar
bien con claves tipo password y hasta la versión 13 si usas jdbc donde las
consultas mal hechas tiene el where pegado por ejemplo aún las dejaba pasar
después del 14 o 15 ya deberías arreglar los SQL que les faltaba un especio en
las condiciones.
Dicho esto ese sistema debería funcionan bien hasta 13. Deberías poder
probarlo. En la noche miro en detalle tu plan de ejecución. Esta mirada la
estoy haciendo desde ingeniero de sistemas y revisa los parámetros que tienes
relacionados a los discos. Búsquedas random vs secuenciales. El planificador
puede pensar que es menos costoso el camino más largo cuando existen parámetros
mal puestos.
Regards,
Horacio Miranda
> On 18 Feb 2025, at 8:48 AM, Guillermo E. Villanueva <guillermo...@gmail.com>
> wrote:
>
>
> Buenas tardes, antes que nada, estoy usando una versión muy vieja de postgres
> por cuestiones contractuales y de un desarrollo de terceros, el proceso de
> upgrade a postgres 17 ya está iniciado, mientras tanto tengo un entorno de un
> postgres 9.2 con un master y un slave con streaming.
> La versión 9.2 está discontinuada de hace mucho así que si quieren dejar de
> leer acá, está todo bien.
>
>
> Tengo una extraña situación con esta query:
>
> SELECT
> OI.org_cod organismoId,
> TE.tex_cod expedienteTipo,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN EA.exp_numero ELSE
> E.exp_numero END expedienteNumero,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN EA.exp_anio ELSE
> E.exp_anio END expedienteAnio,
> E.exp_fecreg expedienteFecha,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN
> REGEXP_REPLACE(EA.exp_carat,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','', 'g') ELSE
> REGEXP_REPLACE(E.exp_carat,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','', 'g') END
> expedienteCaratula,
> A.act_id actuacionId,
> A.act_numero actuacionNumero,
> AF.a_fir_fecha actuacionFechaFirma,
> REGEXP_REPLACE(A.act_titulo,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','',
> 'g') actuacionTitulo,
> CASE
> --WHEN AF.a_fir_fecha::date>='17/11/2020'::date THEN
> UF.usr_nombre
>
> WHEN AF.a_fir_fecha>=date_trunc('day', TIMESTAMP
> '2020-11-17 00:00') THEN UF.usr_nombre ------- Ajuste Formato de Fecha
> 17-02-2025
> ELSE OI.org_descorta || '-'|| 'JUEZ'
> END actuacionUsuarioFirmante,
> REGEXP_REPLACE(A.act_titulo,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','',
> 'g') actuacionTipo,
> encode(A.act_pdf, 'base64') actuacionArchivoPdf,
> REGEXP_REPLACE(AA.aac_nombre,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','',
> 'g') adjuntoNombre,
> encode(AA.aac_adj, 'base64') adjuntoArchivo
> FROM
> act A INNER JOIN
> exp E ON (A.exp_id = E.exp_id) INNER JOIN
> tex TE ON (E.tex_id = TE.tex_id) INNER JOIN
> org OI ON (E.org_idradactual = OI.org_id) INNER JOIN
> act_fir AF ON A.act_id = AF.act_id INNER JOIN
> usr UF ON AF.usr_id = UF.usr_id LEFT JOIN
> aac AA ON A.act_id = AA.act_id LEFT JOIN
> aex AE ON E.exp_id = AE.exp_idacum LEFT JOIN
> exp EA ON (AE.exp_id = EA.exp_id)
> WHERE E.exp_id IS NOT NULL AND A.act_id = 29803286 AND AA.aac_id =
> 1885944;
>
> con un muy buen plan de ejecución, que aprovecha índices al máximo, yo la
> ejecuto desde mi cliente (pgadmin) con los mismos id's y demora menos de 1
> segundo, y así pasa normalmente desde la aplicación tambien, pero hay
> momentos en que sucede algo y esa misma query demora varios minutos!!.
> La query tiene la particularidad que a dos columnas les hace un
> encode(columna, 'base64')
> y sospecho que eso puede estar causando algo raro,
> Esta query va siempre contra el servidor slave y su plan es:
> "Nested Loop Left Join (cost=0.00..18.38 rows=2 width=349) (actual
> time=0.087..0.089 rows=1 loops=1)"
> " -> Nested Loop Left Join (cost=0.00..15.62 rows=2 width=254) (actual
> time=0.070..0.071 rows=1 loops=1)"
> " Join Filter: (a.act_id = aa.act_id)"
> " -> Nested Loop Left Join (cost=0.00..12.94 rows=1 width=224)
> (actual time=0.061..0.062 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..12.66 rows=1 width=216) (actual
> time=0.055..0.056 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..10.18 rows=1 width=203)
> (actual time=0.051..0.052 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..7.03 rows=1
> width=187) (actual time=0.027..0.028 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..6.75 rows=1
> width=173) (actual time=0.023..0.023 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..6.47
> rows=1 width=178) (actual time=0.020..0.020 rows=1 loops=1)"
> " -> Index Scan using or_pk_act
> on act a (cost=0.00..3.81 rows=1 width=51) (actual time=0.011..0.011 rows=1
> loops=1)"
> " Index Cond: (act_id =
> 30580021)"
> " -> Index Scan using
> or_rg_temp_229645822_1 on exp e (cost=0.00..2.64 rows=1 width=135) (actual
> time=0.007..0.007 rows=1 loops=1)"
> " Index Cond: ((exp_id =
> a.exp_id) AND (exp_id IS NOT NULL))"
> " -> Index Scan using or_pk_tex on tex
> te (cost=0.00..0.27 rows=1 width=11) (actual time=0.002..0.002 rows=1
> loops=1)"
> " Index Cond: (tex_id = e.tex_id)"
> " -> Index Scan using org_pkey on org oi
> (cost=0.00..0.27 rows=1 width=30) (actual time=0.004..0.005 rows=1 loops=1)"
> " Index Cond: (org_id =
> e.org_idradactual)"
> " -> Index Scan using or_ix1_act_fir on act_fir af
> (cost=0.00..3.15 rows=1 width=24) (actual time=0.024..0.024 rows=1 loops=1)"
> " Index Cond: (act_id = 30580021)"
> " -> Index Scan using or_pk_usr on usr uf
> (cost=0.00..2.47 rows=1 width=29) (actual time=0.004..0.004 rows=1 loops=1)"
> " Index Cond: (usr_id = af.usr_id)"
> " -> Index Scan using aex_idx1 on aex ae (cost=0.00..0.27
> rows=1 width=16) (actual time=0.004..0.004 rows=0 loops=1)"
> " Index Cond: (e.exp_id = exp_idacum)"
> " -> Index Scan using or_aac_fk1 on aac aa (cost=0.00..2.65 rows=2
> width=38) (actual time=0.007..0.007 rows=1 loops=1)"
> " Index Cond: (act_id = 30580021)"
> " -> Index Scan using or_rg_temp_229645822_1 on exp ea (cost=0.00..1.35
> rows=1 width=111) (actual time=0.000..0.000 rows=0 loops=1)"
> " Index Cond: (ae.exp_id = exp_id)"
> "Total runtime: 0.207 ms"
>
> Tengo configurado en postgresql.conf que haga log de sentencias de mas de 6
> segundos y aparece esta query demorando algunas veces mas de 20 o 30 segundos
> y aun mas.
>
> Hemos revisado los ajustes del postgresql.conf y varias cosas mas y parece
> estar correcto.
>
> Para los que se animaron a leer hasta acá, tienen alguna sugerencia de que
> puedo revisar y probar?
> MUCHAS GRACIAS!
>
>
