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!
